Team Size and Organizing Effective Teams
Photo by Bob Franklin
Originally Scrum was recommended for teams of 7 +/- 2 people; now it is described as 6 +/- 3 people. In either case, a team of 15-30 people is frowned up--it's too large of a group to be cohesive. But I've witnessed large organizations create these large teams through their "resource allocation" processes, and for whatever reason, the idea of this large group splitting into smaller teams is scary or confusing to the Project Managers/Scrum Masters, and therefore avoided. Perhaps it's fear of additional work facilitating meetings for multiple teams. Maybe it's fear of overstepping his or her job duties. Regardless of the reason, it's often allowing teams to be less effective.
An article in the Harvard Business Review states that "less is more in teams" and cites the Ringlemann Effect, which argued that people's efforts diminish as team size increases due to the difficulty to coordinate effort. But a second study later showed that people's efforts diminish in larger teams due to social loafing. When a team is focused on delivering working software in short iterations, it doesn't allow for much social loafing by its members--at least not for long. It is up to the team to reflect upon itself and its work, and I suspect that it won't be too long before social loafers are being called out by the other team members to do their part or leave the team. It might manifest during a retrospective, or it might mean team members privately talk to the Scrum Master. But the issue will become evident with time.
How should a large team be divided? According to Ken Schwaber, one of the founders of Scrum, it's not the Scrum Master's responsibility to organize the teams. In fact, it is particularly wise to let the teams self-organize themselves since when we choose for ourselves, we are far more committed to the outcome by a factor of five to one. Organizations, particularly large ones, seem to rarely allow teams to self-organize, and it's a shame. Teams will be working on complex projects in what is likely a complex environment, and they need every advantage they can get; why not let them start by choosing for themselves as much as they can?
