- About Environment, Products, Size, and People
- Consider Specialization First...
- ...And Generalization Second
- Widen People's Job Titles
- Cultivate Informal Leadership
- Watch Team Boundaries
- The Optimal Team Size Is 5 (Maybe)
- Functional Teams versus Cross-Functional Teams
- Two Design Principles
- Choose Your Organizational Style
- Turn Each Team into a Little Value Unit
- Move Stuff out to Separate Teams
- Move Stuff up to Separate Layers
- How Many Managers Does It Take to Change an Organization?
- Create a Hybrid Organization
- The Anarchy Is Dead, Long Live the Panarchy
- Have No Secrets
- Make Everything Visible
- Connect People
- Aim for Adaptability
- Summary
- Reflection and Action
This chapter is from the book
This chapter is from the book
This chapter is from the book
The Optimal Team Size Is 5 (Maybe)
What is the optimal team size? This is one of the most interesting boundary issues and an important question people have been discussing ever since they teamed up and killed the first mammoth.
I once attended an inspiring conference session hosted by social complexity expert Joseph Pelrine, who told his audience that the sizes 5, 15, and 150 have been mentioned in (or can be derived from) scientific research as being optimal sizes for social groups.
The Agile movement, with Scrum as the leading method at the time of writing of this book, often mentions a preferred team size of "7 plus or minus 2" (which is just a software developer's way of saying "between 5 and 9").
Research into optimal group size for decision making revealed that only numbers below 20 appear to work well [Buchanan 2009:38-39]. Anything from 20 and up can hardly be called a team. When the number of people is too large, we should just call it a group. (I'm writing this text secretly while attending sessions at the Scandinavian Developers Conference, which has 600 attendees. That's a group, not a team.)
Buchanan's article makes an exception for team sizes of 8, which do not appear to work very well. That's because eight people frequently find themselves in a deadlock situation over their decisions. It is said that King Charles I, the only British monarch ever to work with a council of eight members, made decisions that were so notoriously bad that he lost his head [Buchanan 2009:39].
Considering these findings, we can easily see that there's only one optimal team size that satisfies all conditions:
- Five
Five is one of the three optimal sizes mentioned by Joseph Pelrine. Five also falls within the preferred range of sizes for Scrum teams. Five is less than 20 and yet unequal to 8. Five is also closest to the optimum of 4.6 team members that professor J. Richard Hackman found in his research [Hackman 2002:116-122]. And best of all, 5 happens to be my lucky number. So it must be true.
Five is also my default answer to any question that I cannot answer without more information. You see, I actually cannot tell you what the optimal team size is! Let's revisit Kurt Lewin's equation for a moment (discussed in Chapter 10, "The Craft of Rulemaking"), and you will see why:
- B = f(P,E)
As discussed earlier, this equation means: a person's behavior is a function of his or her personality and his or her environment. And because communication is part of a person's behavior, a different version of this equation could look like this:
- C = f'(P,E)
It means a person's communication is a function of his or her personality and the environment. And when we're talking about a whole group of people, and realizing that team size is a communication issue, we can rewrite the equation to look like this:
- S = f"({P},E)
This version means the optimal size of a team is a function of the set of people's personalities and their environment.
In other words, the value of S can be anything! For the Apollo 11 moon landing, the optimal team size was 3. In rugby, the team size is 15. Apparently, the optimum for team size depends on the project, the people, and their environment. But statistically, across all teams in all businesses, the optimum could be 5, and a few numbers close to 5. And if we want to describe this as a range, we could say "between 3 and 7" (or for software developers, "5 plus or minus 2"), which neatly cuts off the 8 (see Figure 13.3).
)
Figure 13.3 Optimal team size: 5 plus or minus 2.
So, what can we learn from this?
My suggestion is not to impose one "preferred" team size on people; although, you might want to add some constraints to team formation. For example, anything upward of 20 is not allowed, with a suggestion to have 5 plus/minus 2 members per team. Then allow self-organization to do its job, and let the people (within their real environment) figure out what their optimum is. Do they want to cut a team of 7 into two teams of 3 and 4? Sure, why not? Are they merging two teams into one big team of 15? Fine, let them see if that works for them. Just make them aware that they might want to reconsider things when the environment or the set of personalities in the team has changed. One final world of advice: Keep your axe ready in case they come up with a team size of 8 (plus or minus 0).