I recently spoke with a Scrum Master of a team of 10 people. He is struggling, as is the team. They are having trouble connecting as a team. They are ok when they work as smaller sub-teams, but not as a team of 10. Well, that's not entirely surprising. There's research backed up by data to explain why.
I've observed over the years that teams of larger than 9 people didn't have what I call the "intimacy" of teams 9 people or smaller. Teams of 3 people or smaller didn't always have the ideas needed, but teams larger than 9 people lost something that was common to smaller teams--an ability to easily communicate with each other. There is a reason for that: the number of communication paths in the team.
The number of communication paths in the team do not increase linearly as the team size increases; team communication paths
square when the team increases linearly. Here is the calculation where N is the number of people on the team: Communication Paths=(N*N-N)/2. That means you have these communication paths for these team sizes:
4 people, (16-4)/2=6
5 people, (25-5)/2=10
6 people, (36-6)/2=15
7 people, (49-7)/2=21
8 people, (56-8)/2=24
9 people, (81-9)/2=36
10 people (100-10)/2=45
That means the number of paths for up to 8 people is still manageable (24), but once you get to 9 people, it becomes 36 paths, which is high. For 10 people, the number of paths is 45, which is unmanageable for most of us. Can some people manage this number of communication paths? Sure. But not many of us, which is the problem. That's why "teams" of 10 people don't work.
If you have a group of 10 people, they will naturally divide into smaller sub-teams of people who can work together. They will not divide themselves evenly, as 5 and 5. Oh no, that would make life too easy. If you are very lucky, they will divide by features. If you are not lucky, they will divide by architecture or by function, or even worse, by clique.
So what does that mean you should do if you have a large team? Here are some ideas:
- Organize by feature. If you have a feature team that's relatively small, as in fewer than 10 people, great. Keep the team that size and stop worrying. You're done.
- If you have already organized by feature and the team is still larger than 9, first see if you have enough people on the team. Do you have enough testers, BAs, product owners, writers, whatever you need? If not, determine what you need. I often see that teams on the verge of becoming programs (collections of projects) do not realize they have to scale, and are trying to "make do" with who they have, which doesn't work at all.
- Once you have enough people, and you've organized by feature, now, ask the people to organize the way that makes sense so that they can get the work done. Do not tell them, "Every team deserves 1.35 testers," because that's how you can divide the testers up. That doesn't make sense. Ask the teams to discuss it and let you know what they need and what does and does not make sense. They will let you know.
If you have a small team, a team of 3 or fewer people, watch out for insufficient ideas to solve the problems. That doesn't always happen, but it sometimes does. Too few people can be just as bad--although differently bad--than too many people. Team size matters.
