Agile Leader Pattern 3 for Building Awesome Teams: Small is Big

Summary

The article advocates for the effectiveness of small teams, emphasizing that the optimal team size for productivity and collaboration is around five members.

Abstract

The article, part of a series on Agile Leader patterns, debunks the misconception that larger teams are more effective by highlighting research that suggests smaller teams are more collaborative and productive. It references studies by Richard Hackman and Neil Vidmar, which found that the ideal team size is approximately 4.6 members, and further research indicating that social interactions become difficult to manage in teams larger than five. The Scrum framework is used as an example, recommending a Development Team size of 3 to 9, but the article suggests that the lower end of this range, combined with the Scrum Master and Product Owner roles, results in an optimal team size of five. It also discusses the benefits of splitting larger teams into smaller ones to enhance collaboration and learning, despite the initial destabil

Pattern 3 — Small is Big

Misperception: Bigger teams have more capabilities to complete the work and ensure the adoption of what is built.

Reality: Small teams promote stronger team collaboration, shared understanding, and productivity. Social loafing is a common problem with large teams.

Richard Hackman and Neil Vidmar researched the perfect team size in 1970². They asked teams varying in size from 2 to 7 members to perform several tasks. Each team was asked two questions:

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 6².

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 Groups³, calculates that once a team grows past 5, the number of social interactions becomes increasingly difficult to manage as shown in Figure A.

Figure A — The effect of group size on the number of social interactions

Also, this study presents 5 as a good number for decision-making. An odd number of members allow for a tiebreaker opinion.

Putting It Into Agile Practice

The Scrum Team has three roles — the Scrum Master, the Product Owner, and the Development Team. The Scrum Guide⁴ 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 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.

Conclusion

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 of a team having diverse perspectives, stability, and small size.

Agile Leader Pattern 3 for Building Awesome Teams: Small is Big

Small teams bring big power.

Pattern 3 — Small is Big

Putting It Into Agile Practice

Conclusion

Related Posts

Other Posts in the Series

References