The Team Is Too Big

Two years ago, Todd was an Agile coach helping a new Scrum master, Jessica, get acclimated to her new role. The first chance they had to jointly observe the development team was when they attended the daily scrum by phone with a few team members in the room. As the meeting time approached, they were both struck by the number of “dings” signaling more people joining the call. In total, 29 people attended.

The development team had grown from 10 to 29 people over the previous year and a half. More people were added as the team became overwhelmed by the numerous projects they were tasked with. In the eyes of management, it was easier to manage a single team than multiple teams, and the team seemed to be doing fine, so there was no urgency to change the team dynamic by splitting them up.

As Todd and Jessica observed the meeting, dysfunctions in the team started to show. There were all kinds of personality types: heroes, firefighters, drifters, you name it. Heck, one person barely showed up to work at all. The team had no concept of incremental delivery nor did they have anything resembling a sprint backlog. They simply had a daily task list that was the discussion point for their 45-minute daily scrums.

Have you ever participated in a daily scrum with 29 people? It’s an overwhelming experience. The purpose of the event gets lost with that many people involved. So, how many people should be on a development team?

The Scrum Guide recommends that a dev team consist of between three and nine people, but that isn’t a hard and fast rule. However, we recommend that you stick to that 3-9 recommendation because experience has shown us that communication starts to degrade if there are more than nine people on the development team. There are, of course, exceptions to this as the team needs to have all the skills to deliver a done increment, but these exceptions are rare.

We’ve talked quite a lot about development team accountability in this chapter. Can a team that exceeds the recommended nine-person size limit effectively self-organize around a problem and have collective ownership of a done increment? Perhaps, but it takes a lot of effort.

There aren’t many sports that have 29-person teams. It would be awfully hard to keep everyone coordinated, plus there’s no way everyone on the field could effectively communicate with each other. If this is true of sports, think how much worse it is in a complex profession like software development.

Is a large team a problem in your organization? Rather than you trying to decide on a new team construction, ask the team to self-organize into new teams. To get started, gather everyone into a large room. Next and most important, make sure everyone understands that the new teams should be no larger than nine people and that each team should have all the skills needed to deliver a done increment of work by the end of each sprint. You can add a fun twist and ask each team to give itself a funny name such as a superhero power or video game. Finally, set a time limit for this activity so there’s an urgency for the group to arrive at a solution fairly quickly. Depending on the number of people, two hours is probably sufficient, though you might need to increase that limit for larger groups.

Letting a team organize themselves into smaller teams may sound like a leap of faith, but it’s something that we’ve done several times with a lot of success. By giving teams the autonomy to do this reorganizing, they immediately start thinking of themselves more as a team rather than a collection of individuals. And if, down the road, you find that the teams need to be reorganized again, you can simply repeat this process.