Best Agile Team Size for High Performance?

Best Agile Team Size for High Performance?

What is the Ideal Agile Team Size for High Performance?

Are you wondering if your agile team is too big or too small, or what is the optimal team size for high performance? We will explore just that question in this blog post. Chances are, your team is bigger than it could be.

When it comes to high-performing agile teams, bigger is not necessarily better. Let’s look at ideal agile team size and why it matters.

My Experience with Different Team Sizes

I recently compiled a list of every team  I had trained and coached since I began coaching in 2012. Turns out that I have helped nearly 100 teams from 20 companies so far. Wow! Even I had not realized the number was so high. And I added to that list the agile team size.

Some teams were just OK, and some were truly high performing teams. And the agile team size varied quite a bit, from teams as small as four to teams as large as 13.

The teams I trained or coached vary in many ways – technology, industry, company size, and product just to name a few. The culture and diversity of the teams is also all over the board.

Lately, I’ve become more curious about the relationship between agile team size, and team performance. I know that four seems small, and 13 seems pretty big. But is there an optimum team size that contributes to high performance?

Agile Experts Say…

As it turns out, Agile experts are not all aligned on the optimal agile team size. Most Agile and Scrum training courses refer to a 7 +/- 2 rule, that is, agile or Scrum teams should be 5 to 9 members. Scrum enthusiasts may recall that the Scrum guide says Scrum teams should not be less than 3 or more than 9.

Jeff Bezo of Amazon was famous for what he called the 2-pizza rule, meaning, the team should be a size that can be fed by 2 pizzas. Though I’m pretty sure that Jeff didn’t have Chicago-style deep dish pizzas like Lou Malnatis in mind when he came up with that rule. (BTW, Lou Malnati’s pizza is the standard for feeding Agile Teams in Chicago.)

lou malnatis pizza - agile teams should be fed by 2 pizzas

And to be clear, when referring to team size I am talking about just the Development team members, not the Scrum Master, Product Owner or others. And when I am talking about Agile or Scrum teams, these are full time, dedicated team members.

Smaller Agile Teams are Usually Better

In reflecting on my list of teams and thinking about their performance, I definitely feel like smaller is usually better. Smaller teams tend to gel more quickly, are much more transparent, and tend to organize more quickly. Coordination is also much simpler with smaller teams.

Growth and maturity seem to be inversely related to team size. The 90 teams on my list were all moving from traditional development to Agile and Scrum so it was important that they learned and grew quickly.

There is also the concept of the bystander effect, which occurs when the presence of others discourages an individual from intervening. In other words, I don’t feel compelled to act because surely one of the many other people on my team will take care of it.

Some of the challenges that seem to be more common with (though not exclusive to) large teams include the following (note that these are almost the exact opposite of the reasons why agile projects are better)

  • Lack of ownership
  • Lack of transparency
  • Lack of psychological safety and trust
  • Reluctance to cross-train and build T-shaped skills
  • Increased specialization and sub-teams (the “testing team”)
  • Scheduling/coordination challenges
  • Difficulty with participatory decision making

Smaller teams tend to be more focused, they move more quickly, and they get more done. They are more nimble, and, er, dare I say it, more agile.

One of the last teams I helped transition from waterfall to Scrum was just 4 team members. The “Flexstars” have high morale and esprit de corps and are well on their way to being a high-performing team.

Changing Philosophy on Agile Team Size

For a long time, most Scrum proponents recommended the seven plus or minus two rule, or the three to nine team member approach. Scrum co-founder Jeff Sutherland seemed to have evolved his thinking about this. In his keynote at the Global Scrum Gathering in San Diego in 2017, Jeff said that he found that 5 was an optimal team size.

What do you think? What has been your experience with team size and team performance? Do you think 5 is better? Or 7, 3 or 9? Please weigh in with your comments.

checklist for remote team productivity

This Post Has 2 Comments

  1. Andre Simones

    I could not agree more. Every team I’ve worked with that had 6 or more team members have instinctually self-organized into sub-teams. Sometimes they divide functionally such as dev and testers. Other times they divide by code/system familiarity. And then the “best”(HA) kind is when they do both, thereby creating their own waterfall process within a sprint.

    Also, every time a team that I’ve been working with has been reduced in size, the productivity has always increased. Every. Time. I’d have to say that this is probably one of the biggest impediments I’ve seen over and over again…”too many cooks in the kitchen”.

    1. Supriya

      Completely agree with Andre as well as the author of this article. My current team size is 20 Developers and I must say it gets really chaotic when planning the Sprint. Too many items are moved from one sprint to next and many items are moved just due to inability of proper estimation.

      Smaller the team, better the performance!!!!!

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.