The Size and Performance of Agile Teams

In discussions around Agile team sizes, conventional wisdom holds that teams should be made up of seven, plus or minus two people.

The Scrum Guide, developed by the co-creators of Scrum, Jeff Sutherland and Ken Schwaber, actually advocates for a number between three and nine. Three people may seem absurdly small, but more than once, I’ve worked with high-producing scrum teams made up of exactly three people.

Here’s the guide’s take (page six, for those of you with your PDF’s handy):

Fewer than three Development Team members decrease interaction and results in smaller productivity gains. Smaller Development Teams may encounter skill constraints during the Sprint, causing the Development Team to be unable to deliver a potentially releasable Increment. Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage.

Amazon’s Jeff Bezos advocates for what he calls “the two pizza rule,” which asserts, simply, that you should be able to feed your team with two pizzas. I was able to eat a whole pizza in college, which could have thrown things off, but the premise makes sense.

So where do these numbers come from? Many in the Agile community will refer to Miller’s “magic number,” although this is a misapplication of Miller’s term; and, it’s not really the concept he was trying to illustrate (and in Scrum, it’s not even the same range).

In Fred Brooks’ “The Mythical Man Month” (if you haven’t read it, go read it right now), Brooks writes:

If each part of the task must be separately coordinated with each other part, the effort increases as n(n–1)/2. Three workers require three times as much pairwise intercommunication as two; four require six times as much as two.

In Brooks’ math, where n is the number of persons on a team, a team of one (let’s call her Alice) only needs to communicate with herself. This is easy for any self-actualized person (though self-actualized persons may be, in and of themselves, a rarity).

Now let’s say Alice is on a team of three. Alice now has to communicate with two other people (Brian and Chris) who each have to communicate with two people (including Alice). You can map their communication by drawing a line from each person on the team to each other person on the team. Their communications network looks like this:

Three people, three lines, three possible (and necessary) vectors of communication. Simple.

Ramp it up to five. Each person has to communicate with four other people. Their new communication network looks like this:

If you are counting, there are now ten possible communication channels in this team’s network.

Now let’s do 8. That’s 7 connections per person. Since connections go both ways, it’s 28 lines total.

What happens in a team of ten? Forty-five possible lines of communication in the team’s network. To quote The Scrum Guide again:

Having more than nine members requires too much coordination. Large Development Teams generate too much complexity for an empirical process to manage.

Often, I see organizations pushing for teams larger than this. Sometimes, it’s because they don’t have sufficient budget or human capital to scale their product ownership resources to accommodate more teams. (This causes problems that we’ll address in a later article.) Other times, management assumes that more people = more productivity (which seems reasonable, on its face). Other times, it’s an innocent matter of trying to make sure good people have good projects or teams to work on, whether those teams need more people or not.

In the mid 2000s, QSM published a study, oft-cited by members of the Agile community, which examines the effects of team size on schedule and productivity. In studying nearly 500 projects, their observations feel intuitive to anyone who’s ever worked on large projects. Yet the solutions to the problems they highlight still run counter to accepted wisdom in most organizations.

Firstly, the team found that productivity per person drops as team size grows, with a sharp drop after the team crosses into the 9- to 11-person range.

From Brooks’ math, we know that a 9-person team’s communication network is significantly more complex than an 8-person team’s network (36 channels of communication vs. 28). The 9-person team assumes almost 30% more communication overhead, simply by adding one person to its roster. This scales similarly in both directions.

Further, they found that projects with teams of 9 to 11 take nearly 2.5 times the effort, as measured in person-months, than project teams of 5 to 7 (167 vs. 69 person-months, respectively). Of course, much of that effort can be parallelized; so the projects, on average, take approximately 40% longer to deliver.

In all, they found that individuals worked most efficiently on teams of 3 to 5, but teams of 5 to 7 people were able to deliver projects slightly faster. Whether the faster delivery justifies the extra headcount is highly situational.

So why are smaller teams more effective?  In addition to the problems with communication overhead that arise in larger groups, we’ll take a look at the Ringelmann effect.

Ringelmann (1913) found that having group members work together on a task (e.g., pulling a rope) actually results in significantly less effort than when individual members are acting alone. Furthermore, Ringelmann discovered that as more and more people are added to a group, the group often becomes increasingly inefficient, ultimately violating the notion that group effort and team participation reliably leads to increased effort on behalf of the members.

Maximilien Ringelmann proved that, as teams grow, individual contribution shrinks, caused by lack of motivation and loss of coordination. One possible cause of coordination loss may be accounted for by network overhead, but on a task like rope pulling, there isn’t much to communicate. Agile methods try to fix the motivation problem by involving people in the reasoning behind their work, though this could be an article unto itself. We mitigate the loss of coordination simply by limiting the number of things we need to coordinate: tasks, user stories, and in particular, people.

On paper, the corroborating evidence in support of keeping teams small seems pretty overwhelming. Yet organizations who endeavor to design the structure of their Agile teams (which may be, in and of itself, problematic for self-organization), will frequently over-staff teams, and as project importance increases, so does the probability of making such a miscalculation and often the probability of failure.

Leaders, Teams, and Agilists alike should understand the cost and benefits of scale. But for anyone who’s ever seen a small team become hyperproductive, it’s not even a discussion worth having.

Agile, Organization Design, Scrum, Teams