From Skill Groups to Feature Teams at Koolicar
A journey through our team growth
Koolicar is a fast growing start-up working on peer-to-peer carsharing. It means that you can rent your car to your neighbor, and earn money for it!
We work hard to deliver the best services and applications to our beloved users. To be able to tackle the challenges of the new technologies and the carsharing industry is bringing to us while keeping up with our users’ needs, we are rapidly growing our technical team.
In less than two years, the number of people in our technical team has multiplied by 2.5. Even though we are still not a large team we needed to learn how to keep everyone working towards the same goals.
We focused on keeping high our velocity and innovation level.
We strongly inspired our thinking with the “Spotify engineering culture”, alose called the “Spotify Squad framework”. The main difference resides in the fact that we keep working with Scrum : we still have Product Owners, as in the Scrum framework, and introduce Business Owners, working closer on business KPIs. While Spotify clearly focused on scaling Scrum to a large group, we focused on keeping high our velocity and innovation level.
Where do we come from and what were our problems?
The last time our development team grew, it was by a significant amount: we went from 6 developers to 10. The numbers are small but it’s actually a +60% expansion in only a few days…
Almost every developer recruited “another himself”. Naturally, each developer welcomed the new member he or she recruited… and so teams were created. Android developers, iOS developers, and Web (front-end & back-end) developers each formed a different team. Three different groups, with three different skill sets, that had to work together. We were organized by skill groups.
A small bunch of people working together generally communicate correctly inside of the group itself. However, communication with somebody outside this group is challenging. Our Product Owner spent a lot of time discussing with stakeholders to manage priorities and emerging new subjects. This did not leave enough time to synchronize with all the skill groups.
Each group started focusing on their own priorities and much less on the work that was being done by the other teams. The outcome of this was:
- We discovered technical incompatibilities between the group that was developing the API and the group that was consuming it (we lost a lot of time here!).
- Our stakeholders were not able to keep track of what was happening: one group would say that a task was completed, while another group would say that two weeks were still required to finish the work.
- Some non retro-compatible updates were deployed in production before the whole system was ready.
We were in need of improvements to stay happy and deliver a product we are proud of. The company needed improvements to better prioritize the work that would add value to our product.
In addition to that, we needed to go faster and push further with our product development. So… we grew again!
The Feature Team revolution
With the new team expansion, the previous problems were amplified. A LOT! We wanted to make a big move. We needed a new team structure to fulfill the needs of both developers and stakeholders. We needed an organization that could be easily extended to more people. We needed an organization that could adapt to our particular situation: a technically oriented team in Montreal, and a market oriented team in Paris. Two teams with a different focus. 6 hours time difference. 6000km between the teams. What a huge challenge, huh?
We chose the “feature teams” schema you can see above. Some new roles were created. Each new team is formed of:
- A Ruby/ReactJS Front End developer
- A Ruby Back End developer
- An Android developer
- An iOS developer
- A UI designer
- A Product Owner
- A Business Owner
In addition to the previous reasons, we are sure that the “feature teams” structure has incredible benefits.
As people are working in small groups, the feature teams allow us, despite the fact that the company is growing, to keep the communications simple and fluid. These small groups also make us all focusing on the same subject and are all working together to get the work done : it clearly improve our feeling of accomplishment.
Having both Product Owners and Business Owners focused on the same part of the product enable fast and direct decision process. Even if the product is becoming bigger and bigger, we still have the possibility to innovate and try new things.
A new role : Business Owner
The Business Owner is the voice of the market, sharing his/her vision and needs to the Product Owner and the team.
Stakeholders and the Product Owner alone were not able to identified and prioritized high added value subjects to work on efficiently. The Product Owner was spread too thin between leading the developers effort, managing priorities and discussing with stakeholders. We realized that the Product Owner had way too much work to do and do all of his follow-ups.
With all of this in mind, we decided to create the Business Owner role. This person is here to improve the business KPIs of the company. He or she is here to ensure that the next priorities are expected by the market and that they fit to the company strategy.
He or she has many responsibilities :
- Know the market inside and out (users, competitors, …)
- Define the priority of high level subjects
- Explain new features and choices to the stakeholders
- Gather feedback and needs from the stakeholders
- Assist the Product Owner in big features descriptions (do not misread me, we do not write “specifications”)
What happened to the Product Owner?
The Product Owner is responsible for going from the idea to a real feature in production.
Seeing what Business Owners do, some of you could be wondering what the Product Owner is now working on.
Actually, we now have two Product Owners: one for each feature team. What we wanted is to allow Product Owners to be more focused on leading and servicing the developers.
His or her responsibilities did not change that much :
- Explain and clarify the vision for the product
- Lead developers during development phase
- Reject the status-quo for better practices
- Find compromises satisfying everyone
- Write User Stories and define priorities, considering Business Owner feedback
- Ensure roadmap feasibility
- Communicate and explains technical constraints to Business Owners and stakeholders
So our new Product Owners are less responsible of the market observation and aligning stakeholders on priorities. They are fully focused on the product and their team. The Business Owners bring the market vision to the heart of the team.
And what about the developers and designers?
Developers are an autonomous crowd within Koolicar, working closely together to deliver the best possible feature in a given amount of time.
Developers and designers now work in an autonomous way, highly focused on the exact same features.
Since the new feature teams are multidisciplinary, we do no have to rely anymore on external stakeholders or teams.
In our previous organization, when a mobile app developer needed the input of a back-end developer to finish his/her task, it was not uncommon that he or she would have to wait until the back-end developer was done with his/her own work to complete his task.
With our feature team, every team member is committed to the same objective : finish the sprint. When something is needed to finish the sprint, developers will always find a mate to help him/her achieving the team goal. We gain both in velocity and responsiveness while reinforcing team spirit.
Since the Product Owner is now more available for the team, a lot of questions can be answered quickly.
Moreover, as the whole team commits to deliver the features set, a whole new team spirit has appeared, improving collaboration and problem solving. Everybody is working for the success of the whole team, and not only his skill group.
Keeping developers and designers linked by their skills : the Guilds
We did not want to lose the strengths that was here when we were working as skill groups : code reviews, architecture brainstorming, technology watch, lunch&learn… To be sure that this part of the previous team spirit stay with us, developers are also structured by guild.
A guild is a group of developer working with the same technology. They are all contributing on different part of the product but with the same technology.
Our code reviews are made by somebody else in the same guild. It ensures that every developer keep an eye on what is happening in the other feature team. It also allows every developer to switch fast to another team if needed (holidays, sickness…).
We do not want to break technical enhancement! To keep our continuous enhancement on a low level, technical brainstormings are organized by guild when needed. In the same idea, we encourage the lunch&learn initiatives.
With this kind of collaboration, mentoring and technology watch are made by the whole guild and everybody is equally improving his skills.
How do we feel now?
With this new organization, we have improved our communication and collaboration. We developed a strong team spirit.
We recentered the discussion about the product subpart managed by each feature team. The teams are now working hard toward product success.
We feel like we created small start-ups inside another bigger start-up.
Having the Business Owner, Product Owner and Developers in the same team, working closer and focusing on the exact same part of the product means the whole feature team is working in the exact same direction.
Since everyone is working towards the success of their feature team, there are no more status quo. Problems are solved quickly, and everyone is much happier to see things moving fast and in the right direction.
Product Owners and Developers can have a lot of conflicts as developers tend to take more time in order to produce quality code, whereas Product Owners want results faster to iterate and test quickly. As Product Owners are now working much closer to the Developers, it creates a good trust atmosphere: compromises are found quicker.
Last but not least, we have also drastically improved communication between the technical team and the stakeholders. The Business Owners, coupled with a brand new transparency culture, are able to share a clear roadmap. Stakeholders are now aware of what will come next and when. And development teams are aware of why we are undertaking some new features.
What’s next?
There is always room for optimization :) Our next challenge is synchronization between teams. We are now highly focused on our scope, and it works perfectly 80% of the time. However, sometimes, teams are working on the same part of the product, or need to touch parts that are held by the other team. In this case, the information stream is not optimal and we know we have to improve this.
Since this new structure works 80% of the time, we will definitely iterate on the current model without restructuring drastically again. And when it doesn’t work so well, in 20% of the cases, we will have to be a little bit more cautious and learn from our mistakes. However, as everyone is willing to succeed, it should be easy for us.
The real challenge will be with our next big team extension: a third feature team is likely to appear. It’s pretty sure that this time, we will need to change again a few things to improve synchronization.
Thanks
A warm “Thank you” to Valentine Hoyet, Holly Le Heux, Eléonore Kuentz and Benoit De Chateauvieux for your multiple reviews :)
