Agile @ Kapten

A year ago, we tried to organize our tech team to serve our phenomenal business growth of 8 000% over the last 3 years. Here’s what we did, and what we’ve learned. It’s a learning process so it may already have changed when you read this.

Early age at Kapten

The tech team was split into small teams, dedicated around technologies and/or businesses. Even though we found some cool names like Newton, Turing or even Tesla, these teams were fully backend teams and there was only one front team dedicated to mobile apps on iOS & Android.

As you can imagine, we sometimes fell into traps where the backend was not complete so mobile developers couldn’t start their work. Another problem was that each team needed to know the full technological stack because there were no specific subjects dedicated to one team or one group of people. There was also no real ownership over the code. This particular issue increased the difficulty for tech teams to add & maintain features on the platform.

We also faced some issues when trying to define our main priorities because we were always trying to prioritize subjects that were essential for a specific department of the company. For example, we tried to decide if we should start working on customer fraud, or add this fancy partnership with Google in the app. Pretty hard to decide because both of these features were necessary but they addressed different needs and added different values.

When you try to do this, you also need to have a great communication inside the company to keep people informed on what’s important and why it’s important.

To address these problems, we asked ourselves 2 questions :

  • How can we increase team autonomy?
  • How can we decide upon and plan our roadmap transparently?

How to give autonomy to your squad?

We learned a lot from Spotify’s organization, so we worked on how to implement our own Spotify-like model at Kapten.

First of all, we created feature teams (or squads), dedicated to a specific part of our day to day business. For example, we have a « B2C acquisition » squad responsible for the in-app signup process, and only this functionality. When you dedicate a team to one functionality, it brings them the power, dynamism and ownership to do the things that matters the most for this feature. It becomes a focused team of experts in a specific domain of your business and responsible for the code behind it.

Second idea : in order for the team to be autonomous, they need to have the full technical expertise of their functional area. So the « B2C acquisition » squad needs to have backend devs, iOS devs, Android devs and a QA engineer. With these 2 ideas in mind, we started working on our user stories to define each squad perimeter.

The next question was : How can you monitor a squad’s performance? Our answer was really simple : choose one and only one KPI that the squad needs to improve.

For the « B2C acquisition » squad, it is quite simple : the team is responsible for the number of daily new users. So they need to increase this number and they monitor it every day. It also became clear that some of our squads were working towards the same KPI, so we started to group them under the same umbrella : Tribes were born.

A Tribe is a set of squads dedicated to multiple KPIs around the same business target.

At Kapten, we’ve created 6 Tribes :

  • B2C : The Tribe dedicated to regular customers
  • B2B : The Tribe that manages our company customers
  • Supply : The Tribe dedicated to our drivers
  • Engine : The Tribe working on making sure all orders are satisfied
  • Platform : The Tribe working on tech tools
  • Operation : The Tribe that manages the production stack

This is it, our Tribe model was born !

Our Tribes were born !

Next thing to work on : How to decide & plan our roadmap so teams can really drive their future ?

How to plan your roadmap transparently?

Planning and deciding a roadmap is a real challenge. About a year ago, our roadmap was a big Gantt-like chart showing projects and team assignments. There were also some crystal-ball charts showing a potential-but-never-could-happen future project.

We tried to maintain this roadmap every 2 weeks but it appeared that :

  • we were very often pushing back projects to make them start as late as possible (compared to ongoing projects)
  • most of our projects were overdue

We were lying to ourselves every 2 weeks maintaining a vicious circle of delays and creating stress with unmet expectations… and nobody wants that!

So we analyzed the essential steps to decide on a project’s future and we figured out that only 3 things matter :

  • What are we doing now
  • What we’ll do next
  • What we are not doing (=or What we’ll do after next is done)

We started building a 3 columns roadmap where we put projects in it. But something was missing : how do we decide which project should be the next ?

We bring back our data-driven-scientist toolbox and KPIs save us a second time ! Every project should have a Return Of Investment. In fact, every project should be measurable. As an example, when you work on projects like integrating Kapten into Google Maps app, the KPI is quite simple : make +XX% more rides.

Ok, so now we have a 3 columns dashboard, we know why we should do a project before another one thanks to our KPIs, but there’s still something missing : we don’t know the cost of the project. And that’s where you need t-shirts ! Every project in our roadmap is evaluated using a t-shirt size : XS, S, M, L, XL, XL+

The idea behind this evaluation is to be able to compare project size and/or complexity when deciding what to do next.

Et voilà ! We can now decide on our roadmap by analyzing the ROI (comparing tee-shirt size & benefits for each project) and choose :

  • What we are doing
  • What will be next
  • What we are not currently doing

It’s become clear that this is not only a roadmap creation process. This is also an amazing communication tool to give power to your squads.

In fact, deciding a roadmap should not be a top to bottom process. It has to be a clearly explainable and measurable thing that everyone can rely on and believe in.

I want to dive a little bit more on this because it’s a REALLY important value that we learned from many companies we discussed with. When you tell people what to do, they do their job as you tell them to. But when you deeply explain why you should do a project, what the benefits will be, and why you need to do it now : people become far more invested and start to climb this giant mountain with you. And our Agile approach allows us to give power to squads whilst still sharing and focusing on the same goal.

To infinity and beyond

This is a sneak peak of how we tried to use Agile to build our own tech process & organization at Kapten. To find our own way, we had many discussions with other companies and learned many things from them. It’s still a learning process and we have many topics to work on like chapters, guilds, career paths and so on..

If we had to share only one piece of advice, it would be: try, take a step back, learn, improve, share and repeat !

If you want to discuss with us, feel free to ask in comment or drop a mail to medium@kapten.com

If you’re searching for a new job, you can find our openings here.

Thanks to Alice for drawings and Alice, Thomas, Jean-Yves, Gilles for correcting this article