By Matěj Nešetřil/ July 20, 2022
It turns out that it is not uncommon for a scrum team to grow to such a size that the advantages of having a team together all the time disappear and the overhead begins to increase. We will look at how to deal with such a situation as simply as possible and avoid inconvenience in this article.
We often come across a recommendation that the size of a Scrum Team should not exceed nine members. We can look at this number as a result of practice, where with just nine people in the team we can maintain principles such as focusing on priorities, estimating the entire team of sprint delivery and teamwork. I’ll leave it up to you whether you perceive the number nine as fixed, or whether you are a little more benevolent in the case when the team operates without scrubbing even above this limit. However, my opinion is that every team will start to face operational and therefore performance problems from a certain size (whether it is at the number of nine, or after the recruitment of the thirteenth member). So, I will generalize the recommendations:The ideal team size is one where all team members are able to contribute to each of the goals and maintain team communication at a level that does not negatively affect the delivery.
From what we have said above, we can deduce how we can tell when our team is growing too much. There are several indicators:
If you know that the time for division has come, be sure first and foremost that the team sees and understands the reasons for its division. You need to communicate these reasons and benefits of division really well. I also recommend communicating with the team in the form of a discussion, not a lecture.
In my first experience with scaling a team, I made exactly this mistake. I considered it sufficient to present the change and not to take into account the comments of the team itself, which will be most affected by the change. This approach resulted in a distrust of the whole change on the part of the team.
In my further experience with the split, we opened the topic with the whole team right at the beginning. It was part of this activity and we took the input from the team into account during the division itself. Thanks to this, people saw that the effort of the whole division is mainly to help the team. Their approach to change corresponded to this, and they themselves went against the change.
Keep in mind at all times that by scaling the team, we are not addressing the discrepancy with the manuals, but the operational problems of the team and the people inside and around it.
An important part of creating new teams from one of the original ones is the selection of the focus of each team. What worked well for me in practice was to revise the goal(s) of the original team:
It may happen to you, as with us, that someone will be needed in all teams. This works temporarily, but we need to have a discussion with these people about whether it suits them.
In general, it should not be a permanent condition. It is necessary to minimize such cases and ideally create a plan for how the person can only join one of the teams as soon as possible. Whether it is through the opening of a selection procedure for a new team member, or the extension of the necessary part of the competencies to someone who is already in the team and is interested in expanding the position.
Organizational changes are, of course, another part of the solution. Personally, the following changes have proven to be useful to me:
The adjustment described above is minimal at first glance and I can confirm that the adjustments have brought us the desired results. And the necessary changes should really be minimal, while achieving the desired goals.
In the final state, practically everyone from the team began to actively participate in the planning. The team also shortened the entire meeting, saving time for everyone. We do not plan to work with each group within a single meeting. The whole team jointly estimates what it can deliver, as everyone has an overview of the content of most scheduled tasks.Teams concentrate on a narrower area covered by the tasks. They don’t have to switch contexts often and move faster in a given area. The joint backlog refinement ensured that synchronization between teams is still ongoing and teams can help each other if needed. In the end, thanks to a joint review and retrospective, a unified identity between the teams was preserved. This is important for good cooperation and maintaining contacts between colleagues.
If you think your team is too big, you may consider splitting it up. I recommend keeping a few basic points in mind:
And from the very beginning, remind the team that the change is reversible. When teams do not work after the split and new problems arise, the team can address everything later. In the extreme case, you can return the lesson to the original state.
Good luck!
THE AUTHOR
Jan Šrámek
Jan Šrámek is an entrepreneur, CEO, and top enterprise-agile coach with many years of experience in corporations and startups. As the founder of Lucid Bay Digital, he connects the world of agile approaches with the reality of business management.
He previously worked as an analyst and architect in the financial sector, which gives him a strong technical and process background. In his work, he applies "agnostic agile," i.e., respect for the context of the company instead of dogmatism. He is known for his diplomacy, patience, and ability to work with demanding teams. Thanks to his knowledge of business, finance, and leadership, he helps companies truly integrate agility into their culture, products, and everyday practice.
GET INFORMED
Fresh Agile Insights
Proven Product Tips
Team Performance Hacks