Why Are Scrum Teams Supposed to Be Small?

One of the things we advocate in Scrum (and really most agile proponents do as well) is small cross-functional teams. I discussed what we meant by cross-functional and some of the reasons why in a previous entry. Now I’d like to look at why we recommend small teams.

Two of the key principles of Scrum are self-management/self-organization and high levels of communication. Bearing on both these principles is the notion of channels of communication as a function of group size. For any group there are a definite number of communication channels (i.e. channel connecting one person to one other person). It turns out there is a reasonably simple formula for that:


What that says is that the number of communication channels (S) for a group of size N is the size of the group multiplied by the size of the group less one all divided by two. As a concrete example we know somewhat intuitively that a group of 3 people has 3 communication channels (think of a triangle with each person standing at a corner; the three lines of the triangle represent the channels of communication)

What happens to the number of channels (S) as the number of people in the group (N) gets larger?

N=6 S=15
N=8 S=28
N=10 S=45

We can notice a couple things going on. Firstly the number of communication channels grows much faster than the number of people. Going from 6 people on a team to 10 amounts to a 66% increase in team size, but a 300% increase in the number of communication channels. Thus whereas a team of 6 has only 15 channels to manage (and 15 channels to use for collaboration) a team with 10 people has 45! 3 TIMES as many. Directly from that we can anticipate that in fairly short order as our team grows above more than about 7 or 8 people our communication network within the team grows to an unmanageable size if we are serious about real time face to face communication (and we should be). Imagine if we ignore Scrum’s suggestion and have a team of 15. We suddenly have more than 100 channels of communication to manage and deal with in our collaboration.

Thus given that Scrum strongly advocates high levels of communication and collaboration within the team (not to mention with the outside world) and given that we prefer the high bandwidth of real time face-to-face communication over any other alternative wherever possible and given that the team is also supposed to self-manage and self organize we can see that the communication problems of a large team are a problem. This is at least part (and in my opinion the largest part) of the reason we advocate small teams in Scrum.

Jimi Fosdick