Several years ago, I wrote a post for a different blog called “Why Team Size Matters.” That post is long gone. I explained that the number of communication paths in the team does 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.
- 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
Here’s why the number of communication paths matter: we need to be able to depend on our team members to deliver. Often, that means we need to understand how they work. The more communication paths, the more the team might have trouble understanding who is doing what and when.
When team members pair, swarm, or mob, they have frequent interconnection points. By working together, they reduce the number of necessary communication paths. Maybe you can have a larger team if the team mobs. (I bet you don’t need a larger team then.
If team members work alone, a daily standup might also solve the problem of “who’s doing what, when, and where?” And, the more people doing individual work, the longer the standup might take.
Now, think of teams who worked quite well together. How large were they? In my career, I have been on teams who delivered finished features with faster throughput. Each of those teams was 4-6 people. Maybe that’s me. (Many of these teams had some form of manager who protected us from management-created mayhem.)
I’ve worked on successful programs of hundreds of people. Many of the teams were 4-6 people. Our program teams (core and software program teams) were closer to 10 people.
The problem with 10 or more people is you have a committee. Committees rarely deliver value. Oh, I’m sure you have seen value emerge from committee, but it takes a lot of work. I most often see is that the committee has people who don’t have the ability to make a decision or disagree with the entire premise of the work.
On the most recent agilepath podcast (the retrospective on safety), there was a place where I went a little berserko about team size. John, the podcast host, mentioned a 30-person team.
I have yet to be on a 30-person anything that accomplished work. I have been on 30-person committees, where I would leave the room. I have been part of 25-400 person programs, where we worked in smaller teams and finished work.
John’s example was, “We need a team to do this particular function. We need a pricing person, etc.” That’s an excellent example of how a program structure would help feature teams deliver a product, not just features. I have yet to see a self-organizing program, but maybe you have.
How could you move towards an organization who is able to self-organize at the product level? Here are several possibilities:
- People become generalizing specialists so they can contribute to the flow of work on any team they are on.
- Teams obsess about seeing their flow of work, to continue to produce valuable features. (Think flow efficiency.)
- Organizations obsess about collaboration and adaptability at the team level, so the teams can finish work that matters.
There’s nothing here about hierarchy. There’s nothing about MBOs or any of that nonsense. The managers change what they reward which is how they can change the corporate culture.
Is that for everyone? Probably not. We are all works in progress.
Here’s my conclusion from that episode: start agile with yourself. How can you contribute to increasing your throughput of your work? Then, work in the team: How can you increase the team’s throughput? How can you make your work frictionless? Once you know how you can work and work in an agile team, what’s the next step for your organization? For many people, it’s program management, just enough structure to release products on a regular basis.
I’m not a fan of organization for its own sake. I like enough structure so I know what I have to do to provide the most value in the shortest time. For me, that means teams of 4-6 people and no hierarchy. That’s me. Your mileage will vary.
For me, that’s why team size matters.
| Reference: | Team Size Matters, Reprise from our JCG partner Johanna Rothman at the Managing Product Development blog. |
