Why I Encourage Small Teams

Yesterday, I was having a conversation with a colleague about an issue she was struggling with.  She was describing to me how management sometimes has the notion that if we just double the project, say from 10 people to 20 people, we will get double the output.  In the classic Mythical Man Month by Fred Brooks, he made the bold statement that resources do no combine linearly.  Brooks documented his observation with a formula that describes, in part, how the exponential increase in communication pathways as the team size grows, is responsible for his observation.

     Communication pathways = [n * (n-1)]/2

In my colleague’s example, the number of  communication pathways increase non-linearly from 45 to 190 after the team doubles in size.  Or if you want percentages, changing the team size from 10 to 20 is a 400% increase in communication overhead.  Wow!  I would call that communication overload.

As a response to this observation, Agile teams and projects almost always try to keep the team size around 8 plus or minus 2.  When team sizes exceed this, it is impossible for people to maintain a network of communication links with all the participants.  

OK, mister big shot consultant, how do you deal with big teams of, say, let’s pick a number, a hundred people? My first answer would be to subdivide the hundred people into smaller units each with 6 to 10 people, or create about about 10 to 12 teams.  Of course, now you have the added difficulty of coordinating that many teams, but no one said management was easy.  However, would you rather coordinate 55 communication pathways between 11 teams or 4950 communication pathways between a 100 individuals?