Team size, pizzas and cohesion
Teams have an obvious pressure to conform to the wider organisation. There is an alternate pressure which is perhaps less obvious. A self-managing team must truly be a team, not a collection of individuals. The team must always look to solving the goals of the team before those set for an individual. This potential conflict tends to become evident in poorly managed iterations.
Work is chosen by the team for an iteration. However it is then assigned to individuals. The individuals work independently on the tasks. This is not the outcome we need – we want the team working together to achieve a common goal.
One factor repeatedly comes up in studies of team integration. Technology organizations have realised that there is a key size for effective teams. Beyond a certain size, teams seem inevitably to become slower, more inefficient and fragmented. This idea has been explored in several communication theories and was popularised by Jeff Bezos of Amazon.
We try to create teams that are no larger than can be fed by two pizzas.
Jeff Bezos
We call that the two-pizza team rule.
Team communication pathways
There are several factors which affect why a team becomes less effective as it grows. Probably the most widely-used explanation is around communication paths.
With three people A, B and C, there are only three possible point-to-point conversations. A to B, B to C and C to A. Even if information were passed only by informal 1-to-1 discussion, there are few options for pathways.
What if the team has grown to ten people? Now there are forty five different potential individual 1-on-1 conversations which could be happening. Each individual talking to every other individual in the team.
In reality information is not shared only by individual conversation and there is broadcast or multi-person discussion. However, the effect still has significant validity. In the larger team there is far more risk of circulating information being localised to individuals or subteams and not being shared across the team.
Past a certain size, communication paths are a key factor in teams fragmenting into subteams.
Team support networks
Probably equally important is the effect of small team size on the level of support supplied. In a small team everyone knows each other well as individuals. They will typically feel more comfortable and this will lead to a higher level of psychological safety.
It is much more clear how everyone’s work fits into the common goal. If you understand how others contribute to a shared objective, you are more likely to collaborate.
Therefore in small teams team members prove to be much more ready both to give and receive support. A team member will be more willing to ask for help because they know the other people on the team. And also a team member will be more willing to give support because they know that the help will make a significant benefit to the team as a whole.
Good practices
There is a general agreement that a specific size of team is most effective. As a leader you should aim to build and strengthen teams of around that size. You should consider splitting larger teams or combining smaller.
However, Bezos’ “two pizza rule” isn’t a specific number. Given typical pizza sizes an interpretation might be up to eight or ten people. That number seems to be widely accepted as the size at which teams start to become less cohesive.
The Scrum Guide suggests a team is “typically 10 or fewer people”. Scrum would include a coach and a product representative in that number so that would be up to eight developers.
My own experience suggests that the smallest viable team size is probably four. And the best upper size is probably eight or less people working on common development. At that point, there will be a tendency to fragment into two sub-teams (which will themselves have viable size).
Larger teams can of course function successfully. However, they (and you as a leader) may have to work harder on maintaining team cohesion.
Leave a Reply