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:

Team_of_3 (2)

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:Copy of Team_of_5

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.Copy of Copy of Team_of_8 (1)

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.

Looking For Better Agile Results? Get Some Design Standards!

With the increasing adoption of agile development, companies are jumping quickly into rapid prototypes of technology projects. This is a great thing, gone are the days of 6–12 month “requirements” phases. However, there are some drawbacks to moving too quickly into rapid prototyping, primarily around reinvention and churn. Teams that jump into projects with little or no standards spend much of their time in the first few weeks thinking about blazing a new path to differentiate themselves. This is great for the creativity process, not so much for consistency across the enterprise and what’s more important: your prototype or test result.

So how do you get to the quick result you’re looking for without all the reinvention and churn? Simple, create a Sprint 0 that focuses on design (and technology) standards. It’s even better if this is part of your agile on-boarding. It’s analogous to cooking with a well-stocked pantry versus letting the team go to the store to buy their ingredients. If you want super creativity, let them go to the store. However, be prepared that this will take much longer, and you will have no idea what’s for dinner for 2–3 hours. Instead, let them loose in a kitchen with a well-stocked pantry and you’re eating in an hour.

Here’s a great example. The U.S. Web Design Standards are published for access to anyone working on a related project. Teams that use a guide such as this will spend far less time debating colors, fonts, and gradients throughout the first 1–2 weeks of a project. Instead, they’ll quickly get busy creating a prototype that they want to brag about.

Want to learn more about how to make Sprint 0 work for you?

4 Things You Need To Successfully Implement Agile

All too often, agile propagates like wildfire between companies. A developer or product manager that has had success at another company becomes a proponent for an agile methodology. The next thing you know, some heavyweight tool has been purchased and developers are left dazed and confused.

Here at Peak we’re believers that if you’re going to do something, you do it well. So, here are 4 things you need to implement agile well.

1. An Agile Coach: Get an expert. Just because we make a mean souffle doesn’t mean we can teach others to make one. A coach may seem like a costly proposition, but the return on the investment will be swift. We’ve seen differences in as little as 3–4 weeks.

2. An Executive Sponsor: Employees watch the actions of leadership very carefully. If you are not bought in at the top, you’ll spend a whole bunch of time talking about agile, and very little time actually doing it.

3. A sticky note budget: Digital tools are fantastic, and really should be all you need. However, when you’re first starting out, nothing beats a physical board with actual notes. It creates habits and reinforces concepts that bits and bytes can’t.

4. A pragmatic approach: Every company is different. Just because something was done a certain way at a previous company does not mean it will work in a new environment. Cultures, people, history, and workload all factor into a successful transition. Instead of adhering to best practices, adhere to the best practices for your company.