Monster teams don’t work, yet the fallacy that bigger is better persists. Is this empire-building, or an attempt to manage the risk of mission failure by overcompensation through team size?
A Scrum master views team size in terms of team dynamics, but a traditional line manager, well-versed in project management, might view this more in terms of span of control.
At the heart of this question is the effectiveness of coordinating resources and engaging in meaningful communications.
The first lesson
My first lesson was how quickly a Scrum master’s span of control can be exceeded. On my first Scrum team, we had thirteen people: eight developers, two business analysts, one QA analyst, one product owner, and me as Scrum master. I used a tri-fold presentation board with sticky notes as my Kanban board. We didn’t have a permanent conference room, and I wanted a visual Kanban board.
During the daily stand-up, I spent most of my time reading and rearranging sticky notes. The problem wasn’t the physical act of moving sticky notes around on a board; that can be solved with software, and by designating a team member to update the Kanban board. The problem was that I couldn’t focus on what people were really saying.
The second lesson
The second lesson was that Scrum ceremonies take much longer with a large team, and the team will quickly lose patience. Larger teams require more interaction. This leads to the common complaint, “Why do we spend so much time in meetings?”
A daily stand-up with six people should take no longer than 15 minutes. That assumes your team has the discipline to apply the recommended “what I did yesterday, what am I working on today, and what are my impediments?” If not, then you should.
A team of twelve can easily take thirty minutes. This doubling of time is true for all the ceremonies and events.
Is your team spending too much time on ceremonies? It’s an important question to ask.
The third lesson
The third lesson I learned, and arguably the most important, was that with more people, there are more conversations and more divergence from the primary focus. Larger teams mean some voices dominate while others are overlooked, not by intent, but by expediency.
Ask yourself: are team members on board with this discussion? Should this topic be explored in more detail? In my experience, those who rarely spoke up were often drowned out, which can have future consequences for alignment and trust.
As teams grow, these scattered conversations often harden into smaller groups. Our team developed two smaller cliques, along with an unaligned group. Each clique had an emerging leader, all vying for dominance. In part, this was for technical leadership, but also for selling ideas and exerting control over the other clique and the non-aligned members. A Scrum master should not be political, but you must keep your finger on the pulse.
Each group would propose radically different ideas. Neither was essentially wrong, but the team needed guidance and focus. It’s tempting to tell them the correct solution, but if you do, you’ve abandoned the Servant Leader approach and are no longer a Scrum master. The number of back-channel conversations increased, as groups championed ideas discussed offline and then debated them with the entire team. This isn’t always a problem, but it heightens contention and extends the time needed to reach consensus.
As quiet team members become drowned out by the dominant voices, passive resistance becomes an issue. No matter how much effort I spent encouraging quiet team members to participate, they remained silent. I think they felt the risks of speaking up outweighed any reward. In one case, a programmer sent a frustrated email to the director about being overlooked and constantly relegated to “bug patrol.” It escalated into a major issue, the kind of tension that builds when concerns aren’t safely raised in the team setting.
Consider incremental changes
It would be nice to say that we solved this problem by splitting the team into smaller teams, but for political reasons, this wasn’t expedient. A Scrum master needs to balance effectiveness vs. expediency. This means you can never get too far ahead of your team or your management. In hindsight, I should have spent the political capital to split the team. It might have paid off, assuming I wasn’t replaced. Your first step must be to gain support from your management and the stakeholders. Be clear as to your reasons and benefits to the team.
Ultimately, I focused on things we could accomplish. My solution was to establish an agenda and table off-topic conversations, especially if only a few people were involved. We were very successful at implementing Scrum estimation techniques and reducing the size of user stories. This impacted communications by keeping the issues focused. Having team lunches helped quite a bit, but incorporating a few more team-building exercises would have been even better. Since we were living under a fixed contract, we didn’t have much discretionary time.
My suggestion would be to investigate various team-building exercises. See if management will support off-site gatherings. Try to be more creative at retrospectives. For example, on a different contract, we played a game called Agile Jeopardy, which tested the team’s knowledge about Agile and Scrum.
Conclusion
When a Scrum team grows much larger than twelve people, it becomes more of a Project Management function. You spend less time facilitating, identifying impediments, negotiating issues, and more time on checking status and management reporting.
If possible, I would advise keeping your team sizes between five and seven. I have found that four Scrum teams were my operational limit as a Scrum master. And two is even better. Small teams provide sufficient bandwidth to focus on responsibilities other than ceremonies and events.
