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.
- It can also be done 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 whole meeting was also shortened, saving each of the team time. It is not planned to work for each group within one meeting. An estimate of what the team is able to deliver is made by the whole team together, because everyone has an overview of the content of most of the 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 and you’re toying with the idea of 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, everything can be solved further. In the extreme case, you can return the lesson to the original state.
Good luck!
Pingback: 10 tips to earn trust with your team as a scrum master - Lucid Bay Digital