When it Comes to Software Development – Size Matters

Sorry for the tongue-in-check title, but when it comes to software development the size of the teams does matter. When I talk to people about good Agile teams, especially good scrum teams, I talk about five attributes – size, co-location, dedication, stability and cross functionality. I also tell them that if we have to make compromises my preference is to make them in reverse order (ie compromise on cross functionality first, then stability, etc. – not that we want compromise). This means that optimal size (7 +- 2) is the most important attribute. Why is this so important?

One reason is that studies have shown that small teams are much more productive than large teams. One such study was conducted by QSM on 564 projects (from their database of over 4000) titled Top Performing Projects Use Small Teams. I urge folks to check out the entire study, but what is most telling is their conclusion:

To complete projects of 100,000 equivalent source lines of code… they found the large teams took 8.92 months, and the small teams took 9.12 months. In other words, the large teams just barely (by a week or so) beat the small teams in finishing the project!

In this study small teams were 5 or fewer and large teams were 20 or more so basically you can pay for 4X the number of people, but you won’t get 4X the productivity.

Tug of WarOther studies have shown that as the size of teams increase that the effort for each individual decreases, even when the people are engaged in physical tasks such as tug of war. This curious phenomenon has a name, the Ringelmann Effect. In addition to other things:

Ringelmann discovered that as more and more people are added to a group, the group often becomes increasingly inefficient, ultimately violating the notion that group effort and team participation reliably leads to increased effort on behalf of the members.

According to Ringelmann, there are two main reasons for this effect – Loss of Motivation and Coordination Problems.

Two Pizza TeamsThe antiquated notion, borrowed from a physical and mechanistic view of software development, that adding people to knowledge work will increase productivity and result in faster software development is still prevalent in many companies, but there are a few software development companies who understand the importance of team size. Amazon, for example, has the concept of two pizza teams. If you cannot feed a team on two pizzas then it is time to split into smaller teams.

The issue of communication (Ringelmann’s Coordination Problems) is alleviated by the two pizza team rule because the number of communication channels increases exponentially as more people are added to a team. This is often described by the equation n(n-1)/2 where n is he number of people on a team. So for teams of 5 (like in the QSM Study) there are 10 communication channels (which is easily manageable) while for the large teams of 20 there are 190! Obviously 190 communication channels is very difficult to manage.

Communication channels would not be a problem is software development was merely a mechanistic activity (as it is all too often mistaken to be), but because software development is a knowledge activity that relies heavily on communication and collaboration, large teams are no a good idea since all the productivity that each new member would bring is easily cancelled out by the additional communication channels (not to mention the attendant loss of motivation).

In my own consulting I have suggested that the simplest way to double productivity of large teams is merely to break it into two smaller teams. My own experience in employing this technique has resulted in a large increase in overall productivity and quality.

As one begins to understand that software development is a complex, knowledge worker activity, one begins to understand that the most important aspect of producing high quality software is communication and collaboration. Communication (and motivation) is optimal when teams are small – so in the end, size does matter.

Leave a Reply