One of the most common questions people ask when trying to implement agile is “What is the recommended size of an agile team?” Even though you’ve probably already seen a number—or a range—during your Googling around, it remains a surprisingly hard question to answer thoroughly. It’s funny how people’s minds often automatically go to “scrum” when they hear “agile.” However, let’s not forget there are many other methodologies and frameworks that live under the agile umbrella. It’s imperative to take their differences into account to answer the title question comprehensively.
Another factor our discussion shouldn’t overlook is scale. Sure, most agile methodologies have been originally designed to help small teams. However, there are specific frameworks that cater to the needs of large organizations. We should certainly take them into account.
Last but not least, we have to factor in the fact the people leave and join teams all the time. Isn’t agile about embracing and responding to change? How does it handle change to its own teams?
All of those questions will be answered throughout the post. Let’s dig in.
What Is the Recommended Size for an Agile Team?
According to many experts on the matter, the recommended size for an agile team is about five to 11 people.
OK, with the TL;DR out of the way, we’re free to discuss the issue in more depth. Why should you favor smaller teams? How do the different agile methodologies handle team size? And what about large-scale agile efforts? We’ll answer those questions and others now.
Generally Speaking, Smaller Teams Are Better
All else being equal, you should favor smaller teams over bigger ones. Why? It all boils down to communication.
Every decision in software development has costs and benefits. This certainly applies to adding new members to a team. Sure, the team will—hopefully—benefit from the experience, knowledge, and perspectives the new member brings to the table. However, every new member in a team increases the communication overhead.
Picture a team with two only two people, Aline and Bruno. There’s a single communication path, or relationship, happening. Now, a third member—say, Claudia—joins the team. Now, the existing communication paths increase to three. Then, a fourth member, David, joins the team. How many relationships now? Six. The number of possible relationships is given by the equation n(n – 1)/2, where n refers to the number of people that belong to the team.
However, Agile Comes in Different Flavors
The scrum guide offers specific guidance regarding team size. However, there’s agile beyond scrum, though many people seem to forget that.
Let’s now see what some of the main methodologies that fall under the umbrella of agile have to say about team size.
What Is the Recommended Size for a Scrum Team?
Scrum has always emphasized the importance of having a small, cross-functional, and self-managing team to create value during each sprint.
How small is small, though? Here’s what the most recent version of the scrum guide says:
The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people.
What Is The Recommended Size For an XP Team?
XP (extreme programming) also favors small teams, with the caveat of the “whole team” considered. “Whole team” is one of the practices of XP. It means that everyone whose skills are needed in the project should be part of the team. However, membership should be dynamic rather than permanent.
For instance, under XP, it’d be okay for a DBA to leave the team once the most complex database modeling tasks are finished. As for exact numbers, different sources seem to agree that XP works better with teams from four to 12 people. Also, since pair-programming is a core practice of XP, keeping that team even-numbered is advised.
What Is the Recommended Size for a Crystal Agile Team?
The Crystal methodology has many characteristics that set it apart from most other agile methodologies. For starters, it isn’t a framework or a single methodology but a family of methodologies. Additionally, Crystal is unique among agile methodologies in that it acknowledges the necessity of handling different team sizes from the start.
Each methodology inside the Crystal family is better suited to a particular scenario that considers several factors, which includes—you’ve guessed it!—team size. The following listing shows the recommended methodology for each team size:
- Clear – teams up to eight people
- Yellow – teams up to 20 people
- Orange – teams from 20 to 50 people
- Red – for larger teams up to about 100 people
What About Agile at Scale?
As we’ve mentioned, most agile methodologies favor small teams. The Crystal family of methodologies is an interesting exception since it prescribes different methodologies according to team size.
However, we can’t ignore the fact that large enterprise organizations exist. Why shouldn’t they also be able to reap the benefits of agile?
With that question in mind, groups have designed frameworks and methodologies to make agile work on a large scale.
Team Size in SAFe
The most famous of such efforts is probably the scaled agile framework, or simply SAFe®. Dean Leffingwell created SAFe with the first release in 2011. It is a framework to help enterprises adopt and apply agile practices on a large scale.
SAFe, similarly to scrum, is opinionated when it comes to team size. Its official page states that teams are groups of five to 11 people. It goes on to say that, due to communication overhead, organizations should favor collections of smaller teams over a single larger one.
Team Size in LeSS
Large-Scale Scrum, or LeSS, is a framework created in 2005 to help organizations apply scrum on a large scale. Teams in LeSS aren’t that different from regular scrum teams. They should be cross-functional, self-managing, long-lived, and co-located. As for team size, 10 should also be the upper limit.
How to Handle Fluctuating Teams
Developers routinely leave for greener pastures. If the organization isn’t doing that great financially, it might let some of its staff go. People retire, decide to switch careers, or pass away. On a less somber note, they might hit the lottery, and—hopefully—they take vacations regularly.
How does agile account for such fluctuations? As it turns out, this is a fairly common question of newcomers to agile methodologies.
The agile methodologies do offer ways to handle such changes. The vocabulary, of course, varies according to the specific methodology or framework. But the gist is this: If you lose a team member halfway through a cycle, that means your capacity—or budget—for work has been reduced. You handle that by renegotiating the scope for the current iteration with the product owner/customer, de-prioritizing the less critical stories.
What if the opposite happens? Well, if a team gains one or more members halfway through a cycle, that means your capacity is now larger. It’s pretty hard to hit the ground running, and most new members will take a while until they’re able to start adding value to a project. However, as soon as they can contribute, their capacity has to be taken into account when doing the planning for the iteration.
There’s More to an Effective Team Than Size
This post discussed team size in agile and how it can affect the software development process. As you’ve seen, agile makes the case that large teams make communication more complex. All else being equal, you should favor smaller teams.
However, if you’re interested in improving the productivity and efficiency of your dev team, there’s much more to consider than what a single number can tell you. You must ensure you’re tracking—and working to improve—important signs about your team’s health. You should foster diversity as well as the healthy conflict of ideas that ultimately arises from such diversity. Ultimately, you should encourage an environment that enables growth, continuous learning, and accountability.
Do you have ideas to share related to this topic? Or maybe you have questions? You might want to check out LinearB’s Discord community.
