November 18, 2021
BLUF: Agile and Scrum Teams with 5-6 team members are best for high performance. The Scrum Guide includes a recommended Scrum team size of between 3 and 9 members. And Amazon’s Jeff Bezos is famous for the two-pizza team rule which means that teams should be sized to consume two pizzas.
This blog describes the optimal and recommended team size for an agile or Scrum team and explores some of the considerations when forming agile teams.
A question that I get frequently is what is the optimal agile team size? For those of you who are just looking for a quick answer, the optimal agile team is just 5 or 6 people. That is 5 or 6 team members and excludes roles like Scrum Master, Product Owner, and God forbid, Project Manager.
But a more complete answer might be that it depends. There are factors that may argue for a larger or smaller team. The recommendation of 5 – 6 is based on my experience with a lot of different teams. It has been my experience that people tend to err on the side of teams that are too big. That creates a lot of unnecessary overhead and each additional member adds less and less to the productivity of the team.
Let’s explore those responses and the considerations for team size. But first, let’s explore what is an agile or Scrum team.
Let’s start with what makes an agile team. Many people use the terms interchangeably and this is understandable. After all, 80% of people who use agile today use the Scrum Framework. Every Scrum team is an agile team, but the converse is not true. There are SAFe teams, Kanban teams and Extreme Programming (XP) teams that would be considered agile teams and they don’t use Scrum. There are even agile squads and guilds (see below) that are not Scrum Teams.
Whether it is good or bad, even the people who use approaches outside of Scrum tend to use the Scrum Roles of Developers, Scrum Masters, and Product Owners. They have become quasi-standard.
Sometimes people ask about the size of agile teams but in fact, they aren’t actually using agile. They spend pondering how many people to put on their “agile” team which is a distraction. That time would be better spent actually learning about and applying agile ways of working. The size of the team is not as important as how they are going to operate.
There are a few questions you can ask to get a sense of whether someone has a true Agile or Scrum Team:
For more details on Agile, check out this post: What is Agile and Why is it Important?
The 2020 Scrum Guide says this about the size of the Scrum Team:
The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. In general, we have found that smaller teams communicate better and are more productive. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.
— Jeff Sutherland and Ken Schwaber, The Scrum Guide (2020)
For the purposes of the best scrum team size, I recommend that you focus on those people actually doing work on the team. In Scrum, that is the developers. That means ignoring leadership roles such as department leaders, managers, project managers and others who don’t actually work on team tasks. Likewise, you can ignore stakeholders, subject matter experts (SMEs), and technical experts that may occasionally help or contribute but aren’t necessarily full team members.
Some people like to use the terms “Core” and “Extended” or Pigs and Chickens to divide between those working on the team and those in more of a supporting role. I just focus on those people who are the developers on the team. Otherwise, you could go around in circles playing WhataboutHer? and WhataboutHim? When in doubt, ask the team who is doing the work. They know who is in the trenches with them.
Jeff Bezos of Amazon was famous for what he called the 2-pizza rule. He said an ideal team is one that can be fed by 2 pizzas. Though I’m pretty sure that Jeff didn’t have Chicago-style deep-dish pizzas like Lou Malnatis in mind when he came up with that rule. And to be clear, Lou Malnati’s pizza is the standard for feeding Agile Teams in Chicago.
How big is a two-pizza team? Certainly no more than 9, depending on how big of an appetite that they have.
Ok, first of all, there is no Spotify model. If you rebranded your teams to squads and tribes to be like Spotify, you may want to do some research on whether that was a good idea
If you do use Squads, my recommendation for smaller being better still applies. Five to six team members would be my recommended size for an agile squad.
So I mentioned above that the Scrum Guide says 10 or fewer Scrum Team members which means 8 or fewer developers. That is in line with what I learned in the first agile training I took years ago where they said agile teams should be 7 +/- 2 people which is five to nine team members. What do other experts think?
One of the first to write about team size for technology projects was Frederick Brooks. In his classic book on software engineering, the Mythical Man Month, Brooks pointed out something that was counter-intuitive – more people on the team can actually do more harm than good:
“Adding people to a late software project is like pouring gasoline on a fire–it just makes it later.”
— Frederick P Brooks, the Mythical Man and Other Essays on Software Engineering (1974)
J Richard Hackman in his great book Leading Teams, described his work with Neil Vidmar in trying to determine the perfect size for a team. Through an informal study, Hackman and Vidmar found that the optimum number of team members is 4.6. They encouraged people to err on the side of too small rather than too large:
That conclusion, of course, was just an exercise done from a not-very-important study, but it does remind us that most of the time smaller is really better. Indeed, a team may actually perform better when it has slightly fewer members than the task actually requires.
— J Richard Hackman, Leading Teams; Setting the Stage for Great Performances (2002)
General Stanley McChrystal in his excellent book Team of Teams said this about optimal team size and his challenge to create a large team that was cohesive:
Small teams are effective in large part because they are small—people know each other intimately and have clocked hundreds of hours with each other. In large organizations most people will inevitably be strangers to one another. In fact, the very traits that make teams great can often work to prevent their coherence into a broader whole.
— General Stanley McChrystal, Team of Teams
As with many things, sometimes the answer to what is the optimal agile team size could depend on your specific context.
I know that I said 5 or 6 team members is my recommended agile team size. That usually works for most situations. Here are some additional considerations that you may need to factor into your optimal agile team size:
You have probably experienced the challenges of working in a large team. While big teams have the potential to get more done, those big teams also suffer from what Ivan Steiner called process losses:
There is also the concept of the bystander effect, which occurs when the presence of others discourages an individual from intervening. Simply put, people don’t feel compelled to act because they assume someone else will take care of it.
A recent Gallup Article described these issues with large teams:
Larger teams tend to be more difficult to lead and more frustrating to work on because members devote more time to organizing their work and less time to actually doing it.
Consider the simple act of taking turns in team conversations. The more people in a meeting, the more people who can — and often will — offer opinions, advice and questions. That slows everything down, no matter how “agile” an organization may claim to be. Misunderstandings and conflict flare because, as teams get larger, it becomes harder and harder for each member — including leaders — to track and respond to the needs of every other member.
— Robert Sutton and Ben Wigert, Gallup
So as we add more team members, each one provides less and less marginal improvement in productivity. There is a point of diminishing returns as you get up to 9 or 10 people.
It is easy to see the increasing complexity and communications overhead that comes with larger teams. Consider the diagrams below which show a comparison of the communication channels for a team with five team members and another with 10 team members. The number of interaction points with a five-person team is 10. That number jumps to a whopping 45 with a 10-person team!
Larger teams are rarely productive. In a team of nine or 10 people, you are more likely to have members gold-bricking and not working to their potential. Given a choice between one team of 10 and two teams of five, I would take the two teams of five any day. To be honest, I would be tempted to take one team of five team members over a team of 10, especially if the team of 10 includes part-time people. I’ve just seen smaller teams outperform larger teams – they punch above their weight!
That is based on my experience with teams of various sizes over the last 15 years. I’ve worked with over 125 agile teams of various sizes during that time including teams I’ve trained, coached, or both. The teams that I had supported varied quite a bit in size, from teams as small as four to teams as large as 13. I don’t think I ever worked with a team larger than 13 though I have heard stories of teams of 25 or more people. I cannot imagine how painful a Daily Scrum would be with 25 people!
When I reflect on those teams and their relative performance, I know that smaller is better. I don’t have quantitative performance data but my experience tells me that smaller teams tend to gel more quickly, are much more transparent, and tend to take ownership of results. Smaller teams tend to be more focused, move more quickly, and get more done per person. There is no room to hide out or coast on a small team.
One of the last teams I helped transition from waterfall to Scrum was just 4 team members. The “Flexstars” had high morale and esprit de corps and were well on their way to being a high-performing team. With just four team members, the Flexstars were a bit of an exception though. I would definitely strive for a team that is five or six team members.