Vitality Chicago Logo

Chicago IL 60604

Vitality Chicago Logo

(312) 767-7691

What is the Optimal Agile Team Size for High Performance?


What is the Optimal Agile Team Size for High Performance?

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

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

My Experience with Different Agile 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 over 100 teams from 20 companies so far. Wow! Even I had not realized the number was so high.

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 was also all over the board.

In terms of performance, some teams were just OK, and some were truly high-performing teams. Almost all the teams I worked with were relatively young in terms of their agile experience.

Finally, those agile teams that I had supported varied quite a bit in size, from teams as small as four to teams as large as 13.

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

Here is What Agile Experts Say about Team Size

As it turns out, Agile experts are not all completely aligned on the optimal agile team size. Most agile enthusiasts will refer to the 7 +/- 2 rule in training, that is, agile or Scrum teams should be five and nine team members.

Scrum took a slightly different approach for the recommended scrum team size. The previous version of the Scrum guide recommended that teams be between three and nine team members. The thinking was that a team with only three people will suffer from continuity issues and may not have all the skills to complete backlog items. On the other hand, if you get over nine team members, the overhead needed to coordinate and communicate tends to bog the team down.

The most recent version of the Scrum Guide made a slight adjustment.They define a Scrum Team as one Scrum Master, one Product Owner and Developers and that is 10 people or less. That means they are recommending eight or fewer Scrum team members.

The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people.

— The Scrum Guide (2020)

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 recommended agile or scrum team size I am talking about just the developers or team members, not the Scrum Master, Product Owner or others.

And when I am talking about recommended Agile or Scrum team sizes, I am talking about full time, dedicated team members. I am not considering those teams that make use of fractional people assignments as shown in the photo below. Are there eight people on that team? Or 4.05 people? I’d prefer 3 full time people than the hot mess shown below.

Optimal Agile Team Size when Using Fractional People

Smaller Agile Teams are Usually Better

In reflecting on my list of teams and thinking about their performance, I definitely believe that 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 100+ 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.

The Flexstars are a bit of an exception but I would definitely look for a team that is five or six team members.

What is the Optimal Team Size for Project Success?

If we look at team size through the lens of project success, smaller teams rule again.

A recent article in the Software Development Times cited a 2007 study of more than 400 projects in the United States and the United Kingdom. Size does matter they said – small teams rule over larger teams.

“The study found that as the project headcount gets larger, the risk of underperformance gets higher. The larger the team size, the greater the risk of failure. A 21 Full Time Equivalent (FTE) project is more than twice as likely to underperform as a 10-FTE project.”

— In Project Management, Size Does Matter, SD Times

This finding should not be surprising if you’ve been around software development much. Fred Brooks wrote this about team size in his classic book, the Mythical Man Month:

“Adding people to a late software project is like pouring gasoline on a fire–it just makes it later.”

— Fred Brooks, the Mythical Man

Changing Philosophy on Recommended 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.

Agile PM book
Share on facebook
Share on twitter
Share on linkedin

2 Responses

  1. 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. 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

Your email address will not be published. Required fields are marked *

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