The Non-Issue of Team Size aka The Incomplete Understanding of Complete Graphs
A football(for my American compatriots, I mean soccer) team has 11 players on the field at any given point in time. This means continuous coordination and communication across 55 possible communication lines. This is for 90 minutes of high-paced, dynamic, and potentially chaotic gameplay. This is why all soccer teams collapse completely within a few minutes of play…
Wait, they don't.
It is a bit more interesting than that. Communication has to be kept up during training and throughout the season, and this actually involves 25 players throughout the season. That is 300 communication channels. How do they do it?
Complete Graphs
The image above shows a Complete Graph, also known as a ‘Fully Connected Graph’. In graph theory, a complete graph is one where every vertex is connected to every other vertex in the graph. The number of edges in a graph with n vertices can easily be calculated using the formula n(n-1)/2.
When it comes to teams, particularly Agile teams, these fully connected graphs seem to pop up all the time as a way to show all the communication paths on a team. They are often used as justification for having smaller teams instead of larger ones. These graphs, shown below, demonstrate the possible communication paths on a team as the size of the team increases.
I have been on teams of 30 to 40 people and teams of 5 to 8 people. In none of those cases did these graphs make any sense to me. My favourite team I ever worked on, with excellent communication, was about 16 people. In none of those cases was the success of the team or the complexity of management ever a factor of the number of people on the team.
For some reason, my personal experience (and that of others who tried these larger teams) did not match the accepted theory. The graphs need to be redrawn…
A Difference Perspective
The basic problem with the Complete Graph representation is that it gives the impression that all the edges in the graph are active at all times. It is important to remember that the graph represents “all possible” communication paths, not “all active” communication paths. Not everyone is talking to everyone else at the same time.
In fact, a single person in a 21-person team is at best conversing with one or two other people, almost never 20 other people. Apply that to all the nodes, and for a 21-person team, you probably have 20–30 active paths at a given time. Same as the fully connected graph would suggest for a 7 or 8-person team.
Even that is not an accurate enough picture. The real question we have to ask is — what is the continuous communication about? For the most part, the communication is about the things we are working on, the work items. People who are working on the same item need to communicate about the details, progress, changes, and issues regarding that work item. The graph for three people working on the same item would look like the one below.
Some Variations
Here, the red node is the work item on which the three team members are working or expected to work together. As you can see, there are three possible communication paths, of which not all might be active at any given time. A team with 6 active items will, by extending the same logic, have at most 18 possible communication paths, sometimes more, but usually less. This is irrespective of the team's size. Below is an 18-person team working on 6 work items with 18 communication paths -
Of course, this is a very clean picture. In reality, the team members are swarming in different ways and dynamically forming associations and communication paths. The paths, though, will always be around the 18 number.
How about the same team working on 10 items? The picture is not as pretty, but might look like the one below -
The number of possible communication paths required has gone up to 30. Further, most folks on the team might need to communicate about at least two items. Some might even need to be aware of three. From our base case of an 18-person team working on 6 items, we increased our Wotk Item Count or Work In Progress (WIP) by 4. As a result, both the cognitive load on the system and the individuals has increased. For some individuals, it is as much as threefold higher.
Now let us talk about changing the other variable in our base case (18-person team, 6 Work Items) — the size of the team. What if these 6 items were being handled by a 6-person team?
If you count the edges in the picture above, you will notice the same 18 communication paths. This time, though, they are distributed amongst only 6 people, which means most folks are communicating about three items, some even having to deal with the context of 4 items.
The Incomplete Understanding of Complete Graphs
Hopefully, the examples above have made a couple of points. There were a lot of graphs and some numbers thrown in, so let us recap them.
- A Complete Graph shows all possible paths, not all active paths.
- The number of paths is more closely related to WIP than the number of people on the team.
- Smaller teams with higher (even 1 work item per person) can lead to cognitive overload for individual team members.
Even more importantly — Why in the world are we trying to manage teams by counting possible communication paths anyway? It is a pretty weird thing to hang your hat on when trying to understand teaming. Help people on the team by lowering their cognitive load. This will allow them to help value items flow through the system. It is more about the number of things they are involved in, not the number of possible communication channels.
Limiting WIP
The obvious result of this is controlling WIP is a much bigger factor when it comes to communication and cognitive load than team size. This is the explanation for why teams of 5, 10, 15, 30, or 60 have worked for many of us in the past. Often with just as much success. Daniel Vacanti and I dove deeper into this in an episode of Drunk Agile.
The other side effect of having lower WIP with larger teams is you indirectly limit WIP at a higher level. Creating new, smaller teams is often done to increase organizational WIP. Every new team gets a new backlog, project, or initiative. That, in turn, increases the project or initiative WIP for the organization.
The Case for Larger Teams
So far, we have made only one point for favouring larger teams. They can help limit organization WIP. The other points discussed here apply to smaller teams as well. As long as we keep WIP low in the same proportion, the loads on both systems and individuals are similar between small and large teams. Esther Derby and Viktor Cessan make similar points in a podcast episode here. They accurately point out that if you do all the things you do for small teams, in a large team context, large teams work just as well as smaller ones.
Even though these things are equal, I would still push for larger teams for three main reasons.
- As we discussed already…Lower Organizational WIP.
- Larger teams mean fewer teams. This means fewer dependencies. That, in turn, means greater organizational agility without having to resort to costly planning and dependency mapping exercises. By having smaller teams, while the teams enjoy agility, we often rob the overall organization of that opportunity. Larger teams that can take care of dependencies internally (hence not have them exist) can help work move through the entire system a lot better.
- Skill availability — as we have understood the importance of the various roles and skills, we have tried to incorporate these into the agile teams. UX, Operations, Marketing, Sales, Legal, and Security, can all potentially be part of the skills required off of the team in addition to the traditional Product, Engineering, and Testing roles. A way to pick up these skills is to have the experts from these areas be a part of the team. This could easily result in a team that requires 6 to 7 pizzas.
There are some other random theories and research that are cited as reasons to have small teams. Let us take a quick look at these.
Dunbar’s Number
This is a commonly misrepresented concept in the conversation of team size. It is pure ‘picking and choosing’ findings to support a point of view. Here is a part of the abstract from Robin Dunbar’s paper
“The number of kin in the network increases in proportion to the size of the family; as a result, people from large families have proportionately fewer non-kin in their networks, suggesting that there is either a time constraint or a cognitive constraint on network size. A small inner clique of the network functions as a support group from whom an individual is particularly likely to seek advice or assistance in time of need. Kin do not account for a significantly higher proportion of the support clique than they do for the wider network of regular social contacts for either men or women, but each sex exhibits a strong preference for members of their own sex.”
This has nothing to do with team size, and the same is true for the entire paper. If we were using this research as a guide, we would hire people from smaller families and have teams segregated by gender.
Miller’s Law
Another theory that finds misapplication at the same time as these misunderstood team communication complete graphs is the psychologist George A. Miller — “ the number of objects an average human can hold in short-term memory is 7 ± 2”. The keyword there is ‘objects’. To me, that describes ‘work items’ a lot more than it describes humans. Miller’s Law is a reason to control WIP on the team, not humans.
Why do “they” Encourage Small Teams?
Why do the common Agile frameworks push us towards smaller teams? The answer is that they do not know how to accommodate more than a “two-pizza” number of people in the ceremonies that are central to their existence. The Dailies, Retrospectives, and Plannings become unwieldy.
I cannot think of a less Agile reason to stop people from doing something — “Do not evolve to something better because our prescribed ceremonies become very hard to do”. That is irresponsible to the point of unethical. You should try things that can make your life and your customers’ lives better regardless of framework recommendations.
Personal experience — A team of 35–40 people can easily get a daily sync done in four to five minutes if they focus on flow. Doing just-in-time retrospectives can reduce your retro meeting into small batches rather than one big meeting. Flow-based continuous planning is also a much better approach than big batch planning once a sprint. It works great for a large team as well. More on these another time.
…Parting Thoughts
The soccer team does not fall apart because there is only one ball in progress. The team would almost definitely fall apart if there were four or five balls in progress. The chaos would be so much fun to watch, though.
We should always be pursuing practices, configurations, and policies that make our system better. We should not let frameworks or experts rule out experiments that can help us improve flow. Ideally, we balance and improve flow at both the team and organizational levels. At the end of the day, team size is only one factor and might be inconsequential. On the other hand, it could be the one thing that has been stopping you from reaching the next level of flow. Do not let misapplied theories and graphs stop you from the experiment.
