According to the Scrum guide, Scrum teams typically have 10 or fewer people, including Developers, Scrum Master and Product Owner. But what happens with a Scrum team that includes more than 10 people? What if the Scrum team has 10, 15 even more people?
First, the events become too long.
All of the events in Scrum are time boxed, which means that they should not exceed a certain amount of time. The Sprint Planning event, for example, is time boxed at 8 hours for a one-month Sprint. For Sprints with a shorter duration, the Sprint Planning event is usually shorter.
Most Scrum teams rarely come close to exceeding the time boxes for the Sprint Planning, Sprint Review or Sprint Retrospective events. However, the larger the team, the longer all of the events take.
For example, the only eight-hour Sprint Planning that I have ever been to was for a team that had almost 20 people in it. Why? Because the more people there are in the Scrum team, the more people there are who need to coordinate together. Each Developer on the team needs to discuss their approach for the upcoming Sprint, and each person needs to understand how the work of all of the others impacts their own approach to product delivery. With so many people working closely together, coordination activities in the Sprint Planning event can quickly become a nightmare. As a result, the duration of all of the events in Scrum becomes longer and longer as the team tries to deal with the extra coordination needs of a larger team.
Some people check out
As a result of the longer meetings required to handle coordination activities for a larger team, team members may start to “check out”, meaning simply that their mind wanders and they are not engaging fully in the discussion. Other team members may accept a sub-optimal approach simply to limit the duration of the meeting.
This lack of engagement diminishes the power of each of these events in Scrum. The power of the Scrum team comes from the ability of a small, cross-functional team to collaborate together to achieve goals, but when that team becomes disengaged, the benefits that the larger organization and its stakeholders receive from the Scrum team are sharply diminished.
Cliques are formed
In an attempt to improve coordination, some teams will develop sub-groups within the larger Scrum team. These cliques may consist of a smaller group of developers who are collaborating together to deliver value within the Scrum team. Communication among the clique may be good and the cliques may be able to deliver value; but the rest of the Scrum team suffers. Those who are not part of the clique have decreased transparency to decisions that are being made and approaches which are being used. They may suffer lower morale as a result of feeling excluded. They may even have dependencies on members of the clique, but may suffer from unnecessary delays as a result of the decreased transparency and communication across all team members.
The team “boss”
In an attempt to reduce the duration of meetings and address the issue of the “clique”, sometimes one person may step forward to tell the other team members what to do, thus cutting through the babble of so many voices. Team members may even welcome such a “boss”, because it reduces the length of Scrum events and lets them get back to doing the work of the Sprint. While the team “boss” may indeed reduce the length of the events and also increase Transparency for all team members, the team does suffer. The team in such a situation will suffer from a reduced ability to collaborate. The power of Scrum is its ability to bring together a cross-functional group of people who collaborate and self manage themselves in order to increase their ability to efficiently meet goals. When a team boss emerges, much of the power of a self-managing team is lost.
Coordination becomes difficult
Even if cliques do not form, and no team boss steps forward, it is still difficult to communicate with so many individuals on the Scrum team. The higher the number of people, the more difficult communication becomes. Some team members may be aware of important decisions, and others may not be aware of them. This greatly reduces Transparency, which impacts the ability of the team to Inspect progress and Adapt. Transparency, Inspection and Adaptation are key to the success of any Scrum team, because they are the foundations of Empiricism. Empiricism means making decisions based on what is known; if many of the Scrum team members are in the dark about the true progress of the Scrum team, it’s difficult for that team to make good decisions and adapt based on current information. For more about Empiricism, check out our recent article Stop Pretending to be Agile.
The solution?
The solution is to allow the Scrum team to self-organize into smaller teams which will together support the same Product. These teams are able to communicate within the team much more easily, and can still coordinate easily when needed to support the Product.
Why let the team self-organize? Wouldn’t it be easier to simply assign them to Scrum teams? The answer is that it might be easier, but teams who are empowered to control how to approach their work - including how to structure themselves into Scrum teams - have increased efficiency and greater team morale. The organization of a Scrum team typically does not impact management authority or organizational reporting structure. Instead, the structure of the Scrum team is more about how the team members will coordinate together to deliver value.
Engaging an experienced Scrum practitioner to facilitate self-organization can help ensure that the event flows smoothly. Below is an example of how a typical agenda for a self-organization session.
- Review product vision, Product Goal and initial Product Backlog (if available)
- Ask team members to introduce themselves and their skills (if they don't know each other)
- Review management’s guardrails
- Have teams determine their structure (e.g. how many teams, how many per team, whether they will be feature teams)
- Have teams identify and remediate weaknesses with their planned structure
- Engage teams in choosing team names
- Teams identify their Scrum Masters
- Present proposed organization to managers
- Managers ask questions
For a step-by-step guide on how to transition to Scrum, check out our recent article What to consider in your transition to Scrum.
Conclusion
A typical Scrum team consists of 10 or fewer members, including Developers, Scrum Master and Product Owner. When Scrum teams become too large, communication and coordination become difficult, which can result in longer, less efficient events, wasted time, poor communication and cliques or team bosses may emerge, which can reduce the ability of the team to self-manage, thus reducing the benefits of Scrum. If your Scrum team has become too large, consider facilitating a self-organization event to allow the Scrum team to organize themselves into smaller Scrum teams which together will continue to work together to support the same product, working with the same Product Backlog and the same Product Owner to deliver value more efficiently to the organization. For a step-by-step guide on how to transition to Scrum, check out our recent article What to consider in your transition to Scrum.