Increase Your Effectiveness with Villanova’s Lean Training – 100% Online!
I’ve written about the importance of team size before, here, here, and here. Previously, this is what I said:
I’ve written about efficient teams before here and here. At Amazon, there is a concept of a 2-pizza team: no team should be larger than 2 pizzas can feed. It’s a great approach to team size. In my short career, I’ve learned how true that rule is. Here’s another thing I’ve learned –
- 2 people are smarter than one
- 3, 4, 5, 6, 7, 8 people are smarter than 2
- a team larger than 9 people is just one big dumb blob
Ok, that’s not true at a wholesale level, but it sure feels like it. A small team with highly smart and capable team members can do much more than 10 mediocre team members. The Wisdom of Crowds mentality doesn’t work that well when it comes to efficiency in teams — especially software teams.
A more quantitative explanation is as follows:
One of the root causes of failure in projects is communication — either a lack thereof, or miscommunication. Large teams are inherently vehicles for bad communication. This is basic combinatorics — for a given project, suppose there are persons A and B. In this scenario there is only 1 communication link. Add person C, now we have 3 communication links, A-B, B-C, C-A. Add person D, then we have 6; Add person E, then we have 10 communication links. Inductively, as team size grows, the raw combinatoric communication link counts grows geometrically, not linearly. To demonstrate this, we use basic statistics of the form n-choose-r, where !, such as n!, is equivalent to n factorial, to arrive at the formula for how many pairs we can choose from n items:
For the number of pairs, we can reduce the above formula to the following:
Visually, as team size grows, the communication links grows non-linearly, but exponentially:
A Rejoinder
Do not let the above dissuade you from large teams; if the product requires a large team, then that is what is needed. Caution, is what I am arguing here. The facts are that the larger the team, the more communication channels there are and the entire process then becomes more error-prone. If the product requires a large team, then expect the above challenge and manage it.
A Conclusion
There is wisdom in Bezos’ notion of the 2-Pizza Team. Small teams work incredibly well. Also, there is wisdom in Toyota’s usage of “The Big Room” as a way to mitigate defects caused by large teams. A combining of the two will most likely make for a great team and a successful product.
 |
 |
 |
||
This post was written by Pete Abilla | ||||
How To Be A Human
Six Sigma Workbook For Dummies — The Raffle
Jeff Bezos and Root Cause Analysis
A Mindless Worker is a Happy Worker
The Apple iPhone Supply Chain
The Toyota A3 Report
Ask Mary Poppendieck Anything!
A Lean Case Interview
Batch-and-Queue or Single-Piece Flow
Multi-Tasking Leads to Lower Productivity
queueing theory: part 1
Zero Defects is Wrong Approach
Overmanaged and Underled
Pull Systems, Push Systems: The Paper Airplane Game
Queueing, Disneyland, and FastPass
Operational Excellence is not a Substitute for Effective Leadership or a Good Strategy
Law of Instinct
Ask Gretchen Rubin: The Happiness Interview
Taiichi Ohno: Teach Others to Think for Themselves
Zipcar Customer Experience: Variability, Utilization, and Queueing
Too Many Cooks in the Kitchen
Colin Powell on Leadership
Visual Management and Self-Reliance
Process Control and Luck
Poka Yoke Example: Prevent Error Through Embarrassment and Humiliation
Quality and Continuous Improvement; 
{ 3 comments… read them below or add one }
Concerning the “Big Room”, there is a bit of research which examined this phenomenon.
“…having development teams reside in their own large room…had significantly higher productivity and shorter schedules… The teams reported high satisfaction about their process and both customers and project sponsors were similarly highly satisfied.”
Teasley, S., Covi, L, Krishnan, M. S., and Olson, J. S. (2002). Rapid software development through team collocation. IEEE Transactions on Software Engineering, 28(7), 671-683.
“Teams in these warrooms showed a doubling of productivity. Why? Among other things, teams had easy access to each other for both coordination of their work and for learning, and the work artifacts they posted on the walls remained visible to all.”
Teasley, S., Covi, L, Krishnan, M. S., & Olson, J. S. (2000). How does radical collocation help a team succeed? Proceedings of the 2000 ACM conference on Computer supported cooperative work, 339-346.
And, then from the Agile software literature, in the book Agile Software Development, Cockburn talks about radical collocation where communication travels through osmosis. Ultimately, people ask more questions and people overhear important conversations. Intentionally putting people phsycially closer also improves the communication.
Nice blog. Keep up the good work!
Tim
Nice post, Pete.
If you’re interested, I had a post a couple years back criticizing the idea of two pizza teams at Amazon:
http://glinden.blogspot.com/2004/08/amazoncoms-two-pizza-teams.html
The basic issue is that the teams do not end up being truly autonomous and attempts to make them independent end up aggrevating communication problems.
Instead of two pizza teams, I argued, Amazon should focus on promoting informal networks (cross-team communication).
I would like to comment on the quadratic law of the number of communication lines.
Statement of the quadratic dependence of the number of lines of communication among people is valid only for small compact groups, where there is a connection between all. With increasing numbers of people, each individual has connections only with its immediate vicinity or environment, which is one of the signs of rationality of large systems. For example, in the design teams with a hierarchical structure is almost no connection between the groups of lower level. Studies show that this dependence is nearly linear, rather with an increase in the number of people asymptotically approaches the linear dependence.
Details you can find here:
http://www.pmforum.org/library/papers/2009/PDFs/july/Barseghyan-Team-Size.pdf
(Formulas (47) and (48) and Fig.8)