A question that I get frequently is what is the optimal number of members for my Agile or Scrum Team? I have two answers:
- First, “it depends”. That is the most honest answer. More about that in a moment.
- Second, for those of you who demand a specific answer upfront, here it is – the optimal number of members for an agile team is 5 or 6 people. That is 5 or 6 team members and excludes roles like Scrum Master, Product Owner, and God forbid, Project Manager.
Let’s explore those responses and the considerations for team size. Based on my experience, I would guess that your team has more than the optimal number of members for an agile team. People tend to err on the side of teams that are too big.
What is the Composition of an Agile Team?
Let’s start with what makes an agile team. Most people who use agile today use the Scrum Framework. In fact, even agile teams that use Kanban or other approaches tend to use the Scrum Roles since they have become somewhat standard.
There are three Scrum Roles – Scrum Master, Product Owner and Developers. A Scrum Team is comprised of one Scrum Master, one Product Owner and several Developers.
- The Scrum Master is a servant leader, coach and impediment remover.
- The Product Owner is the voice of the customer – they set priorities and make decisions about what is valuable for the team to build.
- Developers are the members of the team that do the work. The term developer is a generic term which includes anyone needed to “develop” the solution.
The latest 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 optimal team size, I recommend that you focus on those people actually doing work on the team. In Scrum, that is the developers. That means ignore 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.
Experts Generally Agree That Smaller Agile Teams are Optimal
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
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.
Before we get to my explanation for why I think the team should be just five or six team members, let’s make sure we are talking about the same thing. We are not talking about teams in general – we are talking about Agile and Scrum Teams.
Is Your Team a True Agile Team?
One of the reasons I often give the response that “it depends” is because sometimes people ask about agile teams but aren’t actually using agile. People throw the term agile around quite liberally and they have different definitions for agile team. Some people even think that you create an agile team by having daily standup meetings.
Many of the people who claim to be using agile actually use something else which is definitely not 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 is really interested in or using an Agile or Scrum Team:
- Will the team be self-managing? Agile teams are self-managing (or self-organizing). That means the people closest to the work figure out how to get the work done. If you have someone outside the team managing tasks and telling the team what to do, well, that really isn’t agile. Not agile.
- What Agile Approach will you use? Some 80% of people using agile today are using Scrum. Will you use the Scrum Framework as described in the Scrum Guide? Will you deliver a finished increment of the solution each Sprint? Or, instead of Scrum are you still using waterfall or some whacky hybrid? Do you have design sprints or analysis sprints, followed by a development sprint and then a test sprint? That’s not agile.
- Will your ‘Agile Team’ own the delivery of the solution? I ask this question because frequently we have a ‘team’ that is little more than a collection of individuals or a group or department. They don’t collectively own the solution. Their efforts are scattered and they are ineffective as a team. Someone outside the team is often needed to corral them (see item 1 above).
- Handoffs? Does the team have all the skills to take the solution from not started as a business need to complete by the end of the sprint? Without handing off to another team? If you don’t, then you may want to revisit how work gets done and design your teams to include everyone needed.
- Do you have dedicated and stable Teams? Are your agile team members dedicated to just one team or do you assign them to 2 or more teams? Though most frameworks don’t dictate that you must have dedicated teams, if you are going to assign people to 3 or 4 teams then you clearly don’t understand agile ways of working or just how ineffective that is. You can choose any team size you want – all will be optimal for YOUR environment. As Rodney would say, it looks good on you though.
If you answered yes to these questions, continue on. If you answered no, then stop reading this post about the optimal number of members on an agile team and go read the post What is Agile.
The Optimal Number of Agile Team Members – Here is Why it Depends
Provided you pass the easy five-question quiz above, here are some of the factors that will factor into your agile optimal team size:
- Team Member Specialization – If you have team members that insist on sticking to their own single primary skillset (“I don’t do windows”) then you are going to need a bigger team than if the team is willing to take on new skills as needed to deliver the solution. This doesn’t mean that every team member needs to have every other skill, it means they are T-Shaped and willing to learn. You can have a smaller and more productive team if you foster learning, skill development and ownership of the Sprint Goals rather than deep specialization.
- Solution Complexity – Is your solution pretty complex? How many team members will you need to take expressed business needs and deliver a solution by the end of the sprint? As you can imagine, this is related to the first item. If you have a complex solution and team members are highly specialized, you are going to need a bigger team.
- Overall Effort & Timeline – Though this may be hard to gauge, you should consider the overall size of your effort and delivery requirements when determining team size. That doesn’t mean that you would want a team of 150 people if you have a Herculean effort, but it may push you to have multiple teams that on average are going to be bigger than they would if you had a smaller effort. Try breaking your big effort into chunks that smaller teams can deliver.
- Are You Providing a Coach? Another consideration is whether you are going to provide some sort of coach or Scrum Master for the team. If you don’t have one, the team will need to spend more of their time on impediments and facilitation than they would otherwise. So you will need a bigger team if you don’t have a Scrum Master than if you do have one.
- Team Maturity and Experience Together – Teams that have worked together and matured through the Tuckman stages of development will be more effective and suffer less from having more members than those who are not as experienced. New teams that have not performed together will spend more time thrashing. Smaller teams also tend to move more quickly from Forming to Performing.
The Decreasing Utility of More Team Members
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:
- Meetings are hard to schedule
- People are less likely to jump in to help (swarm)
- Less feeling of ownership to the team’s goals and work
- Lack of transparency
- Lack of psychological safety and trust
- Reluctance to cross-train and build T-shaped skills
- Increased specialization and sub-teams (the “testing team”) within the team
- Difficulty with participatory decision making
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!
Why I Prefer Teams of Five or Six Team Members
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 for results. Smaller teams tend to be more focused, they move more quickly, and they 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.