This post continues the analysis of J. Richard Hackman’s article, The Six Common Misperceptions About Teamwork1. Building on the first two posts on Encouraging Different Perspectives and Stabilizing teams, this third post in the series debunks the thinking that larger teams are more effective.
Pattern 3 – Small is Big
|Bigger teams have more capabilities to complete the work and ensure adoption of what is built.||Small teams promote stronger team collaboration, shared understanding, and productivity. Social loafing is a common problem with large teams.|
- Is your team too large for the task at hand?
- Is your team too small for the task at hand?
Most noteworthy, the results of the study showed that the optimal number is 4.6 team members. This rounds up to 5. Also notable, Hackman was known for never allowing team sizes larger than 6 in his classes at Harvard. According to Hackman, there was a notable decline in operation when teams in his classroom grew larger than 62.
As the size of a team expands, the number of social interactions required to keep members of the team in sync grows exponentially. Notably, a study on How to Design Small Decision Making Groups3, calculates that once a team grows past 5, the number of social interactions becomes increasingly difficult to manage as shown in Figure A.
Also, this study presents 5 as a good number for decision making. An odd number of members allow for a tie breaker opinion.
Putting It Into Agile Practice
The Scrum Team has three roles—the Scrum Master, the Product Owner, and the Development Team. The Scrum Guide4 recommends Development Team size be between 3 and 9 members. This does not include the Scrum Master and Product Owner. Using the research above on small team sizes, the optimal Development Team size is at the lower end of the range—3. Adding in the Scrum Master and Product Owner will arrive at the ideal team size of 5.
However, for your team to have all the skills necessary to develop your product, the team may need additional Development Team members with the appropriate skill sets, requiring the team to migrate to the higher end of the Scrum guideline. As the team members learn from each other over time and become more fungible, the original skill gap that required additional team members will no longer exist. The larger team can then consider splitting into two teams.
However, splitting the team should be weighed against Pattern 2—Stabilize Teams. If a team is on the larger end of the Scrum team size range, splitting will add significant benefits to the team’s collaboration, shared understanding, productivity, and ability to learn from each other. Furthermore, this gain will likely outweigh the temporary destabilizing impact of splitting the team into two.
As always, you should let the team decide on when and how to split. Usually, the team will naturally self-organize into smaller sub-teams within a larger Development Team size. Once the sub-teams are norming or performing, formally splitting the two sub-teams becomes an easier and more favorable option.
The third pattern—Small is Big—goes against common wisdom that adding members to a team will increase a team’s productivity. A small team will find it easier to stay on the same page, collaborate, finish work, and learn from each other. Our posts to date emphasize the importance to a team of having diverse perspectives, stability, and a small size.
Stay tuned for the next post on pattern 4—Enable Face-to-Face Interaction.
- Agile Leader Pattern 1 for Building Awesome Teams: Encourage Different Perspectives
- Agile Leader Pattern 2 for Building Awesome Teams: Stabilize Teams
- The Six Common Misperceptions About Teamwork, Robert J. Hackman, June 7, 2011
- The Power of Number 4.6, Fortune Magazine, June 12, 2006
- How to Design Small Decision Making Groups, Intuitor.com
- The Scrum Guide – The Definitive Guide to Scrum: The Rules of the Game, Ken Schwaber and Jeff Sutherland, November 2017