Many tech companies work with feature teams. What steps do you need to take to introduce feature teams? Feature teams: 1-to-1 relationship between team and features. Components are shared across multiple teams. This story follows-up on my previous post titled . If you do not know what component teams or feature teams are, I would start there first. “Why your development team might be slowing you down?” _“Why are we still releasing new features so slowly?”. I was thinking about this a year after joining a fast-paced…_hackernoon.com Why your development team structure might be slowing you down I helped introduce feature teams at a tech company with around 200 employees. I was not able to find any personal experiences or lessons learned from introducing feature teams. So I decided to write a post to share my personal experience of introducing feature teams. I hope it will make life easier for others considering to roll out feature teams. To move to feature teams we performed the following steps: Getting buy-in to transition to feature teams. Figuring out structure of feature teams. Rolling out feature teams. At the end of the article, I will explain what I would do differently based on the knowledge of how it turned out. 1. Getting buy-in to transition to feature teams. Getting buy-in to change to feature teams is hard. It is a big organizational change. How do you get the right people to support the introduction of feature teams? There were only a handful of people who thought our component team structure was causing problems. If you point out a problem and nobody cares, then good luck changing anything. It took more than a year to convince the company to switch to feature teams. So making it happen required a lot of persistence and patience. “The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore, all progress depends on the unreasonable man.” — George Bernard Shaw I attempted to get buy-in by making the problems of the current situation visible. By showing how certain problems the management wanted to fix, were linked to our component team structure. This approach failed. I was unable to convince key decision makers the problem was worth fixing. I was struggling to make the problem obvious. My conclusion was the problem was not as apparent to others. We just started using Scrum. I was telling them to come and fly to the moon. In their mind we just performed our first manned flight. To make the leap smaller, we arranged a Scrum training together with our People and Talent department. We wanted a trainer who had seen many different companies. This way he could give practical examples from other companies that do things well. The aim of this training was to get everybody on the same footing in terms of Scrum and Agile knowledge. To get everybody on the same page about what matters and the direction to head in. The Scrum trainer we hired was really good. We made an improvement backlog together with the whole team at the end of the training. The trainer proposed to start working with feature teams. All attendees were convinced this was the way to go. After the training there was enough buy-in to start thinking about how to move to feature teams. 2. Figure out structure of feature teams. With the buy-in from the right people in the company, there was a green light to change things. So the first action on our agenda was to figure out: what feature teams do we need? I worked together with a developer ( ) who was technical and good at communicating technical things. We were a good duo, because I knew all features in our product and he had a good picture of our software architecture. Piotr Ilczuk We came up with the following approach: List all teams and the components they are responsible for. List all features and link them to associated components. Divide features over the current teams based on this information. Try to find out if there is a common theme we can discover for each team. Give the team a descriptive name based on the common theme. Sit with the senior members of each team and ask for their feedback on the structure. Adjust if necessary. The first three steps are clear and straightforward. The hardest part was dividing the features over the different teams. The team responsible for the Elasticsearch component should own searching and filtering. The component and the feature belong together. Should the team responsible for uploading, also be responsible for the metadata that gets added on upload? As this information will need to be synced to Elasticsearch as well? There are no easy answers for these questions, but in general we used the following guiding principles: Minimizing the interactions between different teams. Moving as few people as possible between teams. People like their team and generally do not like moving to another team. Minimizing knowledge transfer. If possible, transferring knowledge was preferred over moving people. Make sure workload is distributed evenly over teams. Once we had a list of all teams and the features that belonged there, then we gave each team a descriptive name. The name should make evident which features belong there. We then sat together a last time and criticized our chart. Would it work? Where would it cause problems? Would we need to move people? Would transferring knowledge be enough or not? How could we transfer the knowledge? The final step was to present the potential new team structure to senior members of each team. We presented it to them and asked for their opinion. Would they like working with these different teams? Would it make their life easier? Are there any features that should be moved to another team? We reflected and implemented all feedback we thought made sense. We ended up with a final list of feature teams and which people belonged to what team. Now it was time to roll out the feature teams! 3. Rolling out feature teams The company was a start-up, so used to moving fast. Once we had the management and senior team members on board, it was just a matter of pulling the trigger. We picked a date and from one day to the next, we worked with feature teams. It was a classic big bang release! Was the roll out super-smooth and without any problems? No. We discovered some issues but nothing that was insurmountable. After rolling out, some people were moved and we also discovered there were some knowledge issues. We also discovered some architectural problems we would need to fix, as some components were tightly coupled to each other. But in the end, there were no big problems and the transition was actually quite smooth. I think this is another example where we got lucky. There could have been far more problems. If a lot of problems had appeared, we would have been unable to mitigate them properly. What would I do differently if I would do it again? To convince the company to roll out feature teams, we should have brought in an external Scrum trainer earlier. If everybody has a different opinion on Scrum and Agile, then it is hard to change things. The Scrum training brought everybody on the same page and made it easier to agree on things. I would have pitched feature teams to my organisation differently. I pitched it as a big organizational change. I would now pitch it as a change we make to one team. Let’s just organize one team around a set of features and try it out. What is the harm in having one feature team to evaluate the benefits and shortcomings? If it works well, we roll out further. If it does not work, then we can just as easily stop it. For figuring out the feature team structure, there were a lot of things we could have done better. The biggest downside to the approach we followed was that it was very hierarchical and in conflict with the self-organisation of teams. The approach fit with the company culture. I still think it was not the best way to do it. Scrum teams should work according to the principle of self-organization: “ Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.” We should have involved all teams in coming up with the team structure. The teams should have had a say in how to work from the beginning. The end result would be that there would be buy-in from all teams. The feature teams were announced without getting the final buy-in of all team members. I just had the buy-in of the senior team members and management. This could have been a fatal mistake. The people who would be affected the most were not involved with coming up with the final structure. We also made some big mistakes when rolling out, but there were no repercussions. It was not very well thought-out and could easily have back-fired. We were risking the following situations to happen with the big bang approach: Discovering the overall feature team structure was sub-optimal. We would then need to reorganize a lot of teams at the same time, again. Finding out architectural problems that would prevent the team structure from working. This would have slowed our whole development velocity significantly. Becoming aware of significant knowledge gaps that would prevent the team structure from working. We would either have needed to suck-it up, move people to different teams or hire new people. I think a gradual approach would have worked far better. We could have just started with a single feature team and gradually rolled out to the other teams. This way we could perform the transition at a speed everybody would feel comfortable with. Then we could reuse what we learned from the first team when we roll out to the second team. I think there are mostly advantages to doing it this way and very few downsides. To summarize: Convincing an organisation to introduce feature teams is hard. You have to figure out what works best for your organisation. There is not a single approach that will always work. Pitch the introduction of feature teams as a change you only want to make to a single team. If it works out, then we can decide what to do next. Involve all teams when defining feature teams. You will get a better result and buy-in for when you roll out at the same time. Roll out feature teams gradually. You can address potential problems gradually then as well. What you learn can be applied when rolling out to the next team. A big bang roll-out can back-fire and undermine your whole transition effort.

Super

Velocity

Too Long; Didn't Read

Developers: Build Less. Deliver More. [Learn how]	

Lessons learned from rolling out feature teams

Too Long; Didn't Read

Companies Mentioned

Maarten Dalmijn

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

Lessons learned from rolling out feature teams

Too Long; Didn't Read

Companies Mentioned

Maarten Dalmijn

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES