For years, I've advocated relatively small teams. Why? Small teams can more easily learn—faster and together. All because they have fewer communication paths.
I was only partially right.
Smaller teams tend to have lower WIP (Work in Progress). Even if a 5 to 7-person team falls into the Everyone Starts Their Own Story trap (see Who’s Playing Agile Schedule Games? or Create Your Successful Agile Project), the team can still know what's going on. But a team of 12-15 people? When everyone starts their own story, no one knows what's going on. The WIP increases dramatically.
Then, I watched Drunk Agile Episode 75: Team Size. Oh boy. I was wrong.
Even though I've heard of 15 to 20-person teams, I'd never seen one work. I either saw component teams or dysfunctional teams. And all because of the WIP.
How Large Teams Become Dysfunctional
When a team has a lot of WIP, the team needs all these communication paths because everyone needs to know what other people are doing so they understand when they can integrate their work. (Yes, that was a long complicated sentence on purpose. That's what it feels like to people.)
Back in the 1990s, I worked as a hands-on program manager for a 12-person team. That “team” consisted of:
- Three original developers, the old guard. (The original architect and developers.)
- Six “new” developers. (They'd all been there for a minimum of two years, but they were still all “new.” That's because the old guard didn't help them learn.)
- Three testers. (One tester had been there for about six years, but the other two were “new,” as in hired in the past two years.)
Each of these three groups was their own functional “team.” In reality, it was worse—everyone was a part of a clique.
This 12-person team had a ton of dysfunction. Some of the dysfunction was due to the culture, which discouraged collaboration. The previous manager had focused on resource efficiency, not flow efficiency, so everyone had “their” own work.
The manager thought that the people would get more done if they started more. But Little's Law always comes true. (I didn't know about Little's Law at that time, but I knew multitasking was a disaster.)
That focus on individual work almost sunk this program. When I asked the developers to work together, they told me they wouldn't get their bonuses. And when I asked them to focus on fixing the problems the testers found, they told me they didn't get paid to fix problems.
I protected their bonuses and asked them to collaborate. That's when the culture of experience spat in my face.
Culture Trumps Everything
Up until I arrived, the “team” culture was anti-collaboration. Culture is what people can discuss, how we treat each other, and what the system rewards. Even when I “fixed” the rewards (I am under no illusion), the people still didn't treat each other well. That was a culture that prized experience—and there was no way for people to get the right kind of experience.
The old guard did not “allow” the “new” people to ask in-depth questions about architecture, design, and how people would collaborate (or not). The old guard didn't answer the questions. (See Retrain Your Code Czar for more of these details.)
I'd like to think I was gentle about my requests, but I'm sure I was not. I insisted on learning sessions at least once a week so everyone could learn from the old guard. Those sessions helped people ask more useful questions. Coupled with tooling changes and more collaboration, the “new” people and the testers changed their behaviors. While the old guard worried about relinquishing their power, they were happier to have a product they could release.
Then, senior management offered kudos when we showed a demo. Finally, we released enough that the customers stopped complaining.
That's an example of what I've seen in large teams: dysfunction, cliques, and high WIP.
The thing that makes large teams dysfunctional? High WIP. The lower the WIP, the more a large team looks like a small-world network, not individual communication paths.
Just blow me over with a feather.
Reduce WIP for Better Results
Every time I've seen dysfunctional teams, those teams had high WIP. Back in the 90s, I knew that stopping the multitasking worked even if I didn't have the words for “reduce WIP.” I also knew that fixing the problems the testers found was almost always more important than starting new work. (Or even finishing that new work.)
But I'd never realized that high WIP is the source of much of the team dysfunction. The higher the WIP, the more management pressure to work alone—even if that's the wrong action.
When teams reduce their WIP, they don't need long standups. If they mob/ensemble, they might not need a standup at all. Even if they swarm, the hourly checkin is relatively painless.
Because teams have to collaborate to keep their WIP low, the team soon learns how to treat each other, how to discuss difficult topics, and who succeeds at what. (And who's not pulling their weight as part of a team.)
Even better, the team soon learns who else they need on their team to keep the WIP low. For example:
- Does this team need to integrate with support? If so, what makes sense to do?
- What about any separate delivery/release team? Does it make sense to make releasing something each team can do alone? What would have to be true to make that work for the organization and the teams?
There's probably more, because every organization is unique and has its own issues.
But the big realization for me is this: Better and faster results start with reducing WIP. You can increase your team size so you don't have to wait for anyone else. But it all starts with WIP.