The Two-Pizza Rule and Other Reasons Why Small Teams Are Better
Brian Fitzpatrick and Ben Collins-Sussman mention in their book Team Geek: A Software Developer's Guide to Working Well with Others that "Software development is a Team Sport." Great software products are built by teams, not by individuals, even though the team size may vary. For optimal software delivery, should the team size be large, or should it be small?
Amazon's CEO Jeff Bezos seems to be a huge fan of smaller teams. He famously associated an ideal team size with what he calls the Two-Pizza Rule. The rule states that the team size should not be larger than what two pizzas can feed.
The science behind why the Two-Pizza rule works is based on the idea that "More communication isn’t necessarily the solution to communication problems — it’s how it is carried out." As the size of the team grows, so does the number of communication links—almost exponentially. With the growth in the number of links, it makes it harder for ideas to ideally percolate.
In his article "Why Big Teams Sucks," Bob Sutton talks about larger teams placing a great deal of cognitive load on team members. This load comes from the fact that a larger team size calls for more focus on the coordination of work than doing the work itself. This is one of the reasons that people start to confuse activities with actions and start to gain satisfaction from doing the irrelevant chores.
The touch-time of the software profession is not coordination of tasks, which is a by-product of larger team sizes. Rather, the touch-time is more about doing actual development or testing, which is a direct value-adding action.
Larger teams also face the the risk of team members getting complacent and engaging in social loafing. Social loafing is when one or more members of a group do less work than if they had to do it by themselves. Some members may over-rely on others to complete the work. One of the possible causes of social loafing is the lack of clarity of roles in large teams.
One of the arguments against larger team sizes is brought forward by Frederick Brooks in his book The Mythical Man-Month. He mentions that the time taken to complete the project does not decrease linearly with increasing the size of the team and quotes what is famously known as Brooks Law, "adding manpower to a late software project makes it later." Brooks law defies the tendency of some managers to add more people to the project in order to contain the schedule.
Like almost every major decision, the formation of teams is often made by management. Larger teams come with their fair share of problems—least of which is lack of alignment and accountability. The best idea is for a leader to choose the right teams, give them the goal, and define how the progress will be measured. Once this is done, let the team deliver on the communicated organization's priorities. Even with smaller teams, the leadership needs to impart sufficient autonomy to ensure the organization's continued success.
Do you agree?
