Nearly every client I work with asks me this question at some point during consulting:
How large should the Development Team be?
How many doers (i.e. exclusive of ScrumMaster and Product Owner) per team? The Scrum Guide offers very limited guidance, suggesting 3-9, without giving reasons or context for those numbers.
Clearly one generic answer can’t define optimal team size for everyone, but it’s worth knowing what factors should be reviewed, and what the tradeoffs are.
Factors that take into consideration the Development Team’s needs are more important than an arbitrary number:
A sufficiently broad set of skills to build their product – aka Cross Functional
Team members dedicated to one and only one team
Stable membership – i.e. team membership is consistent over a long period of time[1]
Diversity of thought (and also background) – a sufficiently broad set of ideas, ethnicity, religion, gender, and life experience all spark creativity and diversity of thought.
Once the Team is formed, the following factors seem as important as team size when predicting success:
Psychological safety – i.e. the environment makes it safe for all team members to share ideas[2]
Collective Intelligence of the Team – which is strongly correlated with average sensitivity of team members[3]
Equal Communication – the most expressive team member is no more than twice as expressive as the quietest[4]
Open Mindedness and Willingness to Learn[5]
Team Size Numbers
The earliest Scrum and XP books all suggest a team size number of 7+/-2, applying Miller’s number[6] – the number of integers you can hold in short term memory – to team size. I’m troubled by the applicability, as I can’t see why one’s ability to keep track of numbers should be correlated with team size. In addition, more recent research[7] has demonstrated that as the things you’re keeping track of become more complex, the number of items you can keep In short term memory drops to 4 or less. So we need more applicable sources.
Many coaches cite historical examples going back to the Roman army and earlier, with small unit sizes of around 8 people. Others observe that Bonobos often split into groups of 6-7 to forage for a day. However, since neither example is about teams doing knowledge work, the relevance to Scrum is limited.
Relationships between Team Members
The official equation is N (N – 1) / 2. But what exactly does that mean? More importantly, how is it going to help us? Let’s take what resembles a math class problem, and turn it into something we can actually use in real life. Who knew?
Basically, it tells us how many different relationships will exist within a team of a certain size. N = the number of people in the Team. So in the first example, for N=5 we have 10 relationships. 10 different combinations of team members interacting and developing a relationship with another team member. In the second example, n=7 so we have 21 relationships, and at n=9 we have 36 relationships. Each pair of people represents one relationship and that relationship is how they collaborate. High-performing teams need to have strong relationships between each of the team members.
Why does this matter? Because each new person adds some individual productivity to the team, however each new person also increases the communications overhead. To increase a team from 5 to 7 people, we have slightly more than double the communication costs to maintain those relationships. To go from 7 to 9, we don’t quite double it, but the jump is still large.
Just how expensive is it to maintain these relationships? Anecdotally, having studied team member interactions at clients’ sites, I can say that in teams of 7-8 people, upwards of 90 minutes, per person, each day is spent interacting with other team members[8]. This excludes pair programming time. Some of the interaction is talking about work, but just as much is spent socializing. Which is fine, and important, because it’s the combination of work and socializing that builds a team’s resilience and ability to handle challenges effectively. (See the water cooler section in “Five Steps Towards Creating High-Performance Teams“.) So relationships between team members, and the time investment they require, needs to be a factor that is considered when choosing team size, because it will influence productivity.
A general rule of thumb suggests that people typically have from 3 to 5 hours of productive time at work each day. So as a Team gets larger, we either lose productivity or, more often, we start to withdraw socially rather than sacrifice productive time on interacting with our peers. We need strong relationships to become a high-performing team but, as group size grows, we start to avoid the interactions that build those relationships[9].
Research Backed Evidence
The American Sociological Association published a study by Hackman JR, Vidmar NJ of the “Effects of size and task type on group performance and member reactions”[10]
Figure 1 – Source: Hackman JR, Vidmar NJ. Effects of size and task type on group performance and member reactions. Sociometry. 1970;33 :37-54.
In this study they got people to complete a number of tasks – a mix of Production (writing), Discussion, and Problem-solving. The participants were placed in different groups sized from 2 to 7. After completing each task, volunteers were asked a number of questions, including two that this graph displays: “was your group too small?”, “was your group too large?”. As you can see from the graph, groups around 4-5 in size seemed to have the least negative reaction. The oft-cited number is 4.6. Key experimental conditions: the volunteers were undergraduate students (all men, sadly), the tasks had a cognitive load but were not programming, and the groups weren’t together long enough for a real sense of “team” to form. Nonetheless, it is an interesting data point.
By the time Hackman wrote the book “Leading Teams” his rule of thumb for team size was 6.[11]
Jennifer Mueller cited in “Is Your Team Too Big? Too Small? What’s the Right Number?”:
if companies are dealing with coordination tasks and motivational issues, and you ask, ‘What is your team size and what is optimal?’ that correlates to a team of six. “Above and beyond five, and you begin to see diminishing motivation,” says Mueller. “After the fifth person, you look for cliques. And the number of people who speak at any one time? That’s harder to manage in a group of five or more.”
But it’s not just personal opinions from team members that educate us on optimal group size; we also have objective statistics. Putnam and Myers surveyed data from 491 projects in a large corporation[12]. These are projects with 35,000 – 90,000 SLOC. They broke projects down into buckets based on the number of people involved in the project: 1.5 – 3, 3-5, 5-7, 9-11, 15-20. On average, the smaller groups (3-5, 5-7) took significantly less time (11.9 and 11.6 months) than the larger groups (17.1 and 16.29 months) to complete similar sized projects.
When you multiply the number of team members times the number of months, you get a graph that is even more shocking:
So a team of 9-11 people took ~2.5-3.5 times as long as teams of 5-7 and 3-5 to complete projects of a similar size. That suggests that teams larger than 7 in this dataset were just a way to spend money faster, because of the increased team size but reduced net performance.
Evidence from Agile Projects
Larry Maccherone, in his work through both Rally, Tasktop and AgileCraft, has helped build large datasets about practices in Agile Teams. His data shows:
Figure 2 – Used with Permission from Larry Maccherone – from Impact of Agile Quantified Late 2014
Based on Larry’s data it would appear that teams of 1-3 are more productive but have lower quality. Teams of 3-5 are marginally more productive than 5-9 although they might still have slightly lower quality – the difference is small. Larry’s notes suggest that he thinks the entire range of 3-9 is fine. I wish the data had split the 5-9 group into separate sets of 5-7 and 7-9 so we could see if there is a noticeable difference in his data at the larger end.
My Experience
Other factors that affect team size choices: larger teams spend longer in forming, longer in norming, and therefore longer to reach high performance. Why? Because there are more relationships to be negotiated. As we saw before, on a team of 5 there are 10 relationships that need to form, a team of 7 has 21 relationships etc. More relationships take more time to build and establish trust.
Assuming that everything else is equal (e.g. skills required to get the job done, diversity of thought, etc…), teams of 4-6 seem the best choice. They take less time to form and have productivity that is on par with larger teams. In addition, teams of 5-6 can typically cross-skill enough to cover the loss of one team member after they win the lottery.
I would only choose a team of 7 if other pressures, like required breadth of skills, forced it to happen. I no longer recommend teams of 8, as the additional overhead overwhelms the value of the extra person.
With teams of 9 or larger I recommend splitting into two teams. My own experience mirrors that of other Scrum trainers and coaches – separate teams of 4 and 5 get more done than their original large team.
Why not 3 or fewer? Because it would be too little diversity of thought, and very challenging to have sufficient skills to get the job done. Also, there will be very little collaboration, which correlates with the reduction in quality that Figure #2 shows (data from “Impact of Agile Quantified”). Finally, there are the obvious two-on-one power issues that may make the journey more challenging for one team member.
However, more important than team size is this: does the team have the capacity to get to truly done (i.e. shippable) at the end of every Sprint?
If it doesn’t, then you want to re-examine and reconfigure to achieve a more effective team size.
What has been your experience with team size? Too small? Too big? Just right?
Thanks to:
Peter Stevens and his own digging: http://www.scrum-breakfast.com/2014/12/how-many-people-do-you-need-in-your-team.html
Larry Maccherone and access to all of his work
Joseph Pelrine for pointing me to original research papers
Brent Barton for telling me about Putnam and Myers
Manoj Vadakkan and Angela Johnson for other references
Pawel Brodzinksi: http://brodzinski.com/2014/01/ideal-team-size-fallacy.html who offers an alternate view
Image attributions: Photodune and Agile Pain Relief Consulting unless otherwise noted.
[1] “Impact of Agile Quantified” – Larry Maccherone demonstrated that dedicating team members to one team doubled productivity and stable teams improved productivity by 60%. https://www.infoq.com/presentations/agile-quantify
[2] “What Google Learned From Its Quest to Build the Perfect Team”: http://www.nytimes.com/2016/02/28/magazine/what-google-learned-from-its-quest-to-build-the-perfect-team.html?_r=0 and Psychological Safety and Learning Behavior in Work Teams – Amy Edmondson Administrative Science Quarterly 1999 44: 350 DOI: 10.2307/2666999
[3] “Evidence for a Collective Intelligence Factor in the Performance of Human Groups” – Anita Williams Woolley, Christopher F. Chabris, Alex Pentland, Nada Hashmi, Thomas W. Malone
[4] “The New Science of Building Great Teams” – Alex “Sandy” Pentland http://hbr.org/2012/04/the-new-science-of-building-great-teams/ar/pr and also “Evidence for a Collective Intelligence Factor in the Performance of Human Groups”
[5] “Wisdom of Teams” – Jon Katzenbach and Douglas Smith – stated that the Skills Potential are as important as the skills people currently have in predicting effectiveness.
[6] Miller’s Number: https://en.wikipedia.org/wiki/The_Magical_Number_Seven,_Plus_or_Minus_Two
[7] The Magical Mystery Four: How Is Working Memory Capacity Limited, and Why? Nelson Cowan –http://www.psychologicalscience.org/journals/cd/19_1_inpress/Cowan_final.pdf?q=the-recall-of-information-from-working-memory
[8] This has been very informal observations – just sitting watching what was going on in team spaces and around the water cooler. This time didn’t include lunch breaks.
[9] This is also documented in: Mueller, J. S. Why individuals in larger teams perform worse. Organizational Behavior and Human Decision Processes (2011), doi:10.1016/j.obhdp.2011.08.004
[10] Stable reference: http://www.jstor.org/stable/2786271
[11] Familiar Metric Management – Small is Beautiful-Once Again – Lawrence H. Putnam and Ware Myers http://hbswk.hbs.edu/archive/2996.html
[12] http://www.qsm.com/fmm_28.pdf