Team Size Matters, Reprise

Several years ago, I wrote a post for a different blog called “Why Team Size Matters.” That post is long gone. I explained that t he number of communication paths in the team does not increase linearly as the team size
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 memberspair, 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 personprograms, 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. (Thinkflow 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 workfrictionless? 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’sprogram 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.



Agile Voices稿源:Agile Voices (源链) | 关于 | 阅读提示

本站遵循[CC BY-NC-SA 4.0]。如您有版权、意见投诉等问题,请通过eMail联系我们处理。
酷辣虫 » 综合技术 » Team Size Matters, Reprise

喜欢 (0)or分享给?

专业 x 专注 x 聚合 x 分享 CC BY-NC-SA 4.0

使用声明 | 英豪名录