Lucid Bay Insights

My experience with team scaling

Agile
7 minutes reading
team scaling

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.

Ideal team size

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.

When to start thinking about splitting a team

From what we have said above, we can deduce how we can tell when our team is growing too much. There are several indicators:

  • Timeboxes in meetings are no longer enough.
  • During meetings, such as planning, separate parts of the team actively rotate, where only one part is actually planned and the other part is working on its sprint tasks (or those currently being prepared).
  • Specialization in various areas is deepening, so that certain topics are so far removed from some that they are no longer able to work on them effectively.
  • The team is not able to uniformly make an estimate of what can be delivered, because not everyone really understands the entire content of this estimate. As a result, only individuals or smaller groups within the team comment on the different parts of the estimate, and the rest rely on their judgment.
  • The team comes up with the suggestion that it is too big and needs to be divided.

What to avoid when dividing and what not to miss

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.

Focus of teams

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:

  • Look at the reason your team exists.
  • Write together what the team is doing and what it should be doing.
  • Together with the team, then start assigning individual members according to competencies to the given goals. However, keep in mind the personal goals of your colleagues. Where they are heading as individuals and what they want to move forward in. In this way, you will create an idea of what is happening in the team, what is supposed to happen there and how the forces are distributed between these activities. According to the result, you should already be able to create individual teams, including their goals.

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.

Change of your team organization

Organizational changes are, of course, another part of the solution. Personally, the following changes have proven to be useful to me:

  • Backlog refinement common to all teams.
    • The team can also do this only among team representatives.
  • Sprint planning separate.
  • Daily separate.
  • Sprint review common.
  • Retrospective common.

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.

Summary

If you think your team is too big, you may consider splitting it up. I recommend keeping a few basic points in mind:

  • Rest assured that the team needs a change.
  • Clearly communicate what change will bring to a positive team and its members.
  • Involve the whole team in the discussion and solve their real problems.
  • Define the goals of each team.
  • In the organization of teams, make only the minimal changes needed to achieve your goal.

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!

Jan Šrámek, agilní kouč, mentor, školitel, CEO Lucid Bay Digital, jednatel společnosti. Agile Expert | Board Level Advisor, Agilní transformace, Produktové transformace, nábor agilistů, nábor scrum masterů, product ownerů a agilních leaderů

THE AUTHOR

Jan Šrámek

Author's Posts

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