Your small team has been doing great. You’ve delivered significant value to your stakeholders. You’ve shown noticeable improvement in how you work together iteration after iteration. And you’ve proven to your organization that this whole “agile” thing can work. In fact, your team has done so well that your organization has decided to reward you by increasing their investment in your team.
After all, if your team has delivered this much value with only a few people, then a team three times that size should be able to deliver the same amount of value three times faster. Right?
Not so fast. While it can be tempting to increase the size of a new team after that team has shown some initial promise, simply increasing the size of an agile team isn’t always the best choice.
Although it may seem surprising, simply increasing the size of an already successful team is not guaranteed to increase that team’s success—and it may even put that team’s chances of future success in jeopardy.
A team is a complex system and increasing its size increases that complexity even further. As a result, it can become more difficult for the team to continue to function in a high-performing state.
One of the most common areas where this becomes evident is in the increase of relationships and corresponding interpersonal communication pathways that are present on the team. Adding one additional team member doesn’t merely add one additional communication pathway—it adds one additional communication pathway between that team member and every other individual on the team. This increase in communication pathways can significantly increase the complexity of that team’s interactions, especially when that team is following an agile practice that emphasizes face-to-face communication.
Illustration by Moe Bonneau.
However, an increase in the complexity of team dynamics isn’t the only challenge faced by teams who have suddenly increased in size. Another surprising challenge is the ability to keep your new larger team busy.
If asked, most organizations will say that they have more work than they’ll ever be able to finish. In fact, this is often the impetus for increasing a team’s size in the first place. However, what many organizations take for granted is how much of that outstanding work is actually ready to be worked on.
Much of an organization’s outstanding work is vaguely defined or only partially conceived. While this can be perfectly acceptable for work far down a team’s backlog, when a team suddenly finds itself with a sharp increase in capacity, this vaguely defined work quickly makes its way to the top. When this happens, the team suddenly finds themselves tasked with work that seems to generate more questions than answers. As a result, the team cannot process this work as quickly as they expected and their new velocity fails to meet the expectations that the organization had for the larger team.
To complicate matters even further, some of this work may be dated and no longer relevant to the product’s vision or may simply be of low value to the product’s stakeholders. Often a product manager will justify investing in this low-value work as a way of keeping a team busy while higher value work is found. However, this assumption ignores the ongoing maintenance costs the team will incur to support this new work as well as any potential increases in technical debt that were necessary to deliver that work. When the total costs to create and support this low-value work are considered over the long term, we often find that it’s more cost effective to simply keep the team idle until truly high value work can be identified.
So, with the all of the challenges that can face larger teams, you may be wondering if simply creating additional smaller teams might be the right choice for your organization. In fact, many organizations find that this can be a very successful approach. Luckily, there are a few specific steps you can take to keep your small teams effective.
The first step is to keep your small teams…well, small. But how small? The Scrum Guide recommends that development teams stay between three and nine individuals. But even the upper end of that range that may be a bit too large for some tastes. Those of us who shudder at the thought of a nine-person team will be happy to know that studies from such management thought leaders as the Harvard Business School or the Wharton School of the University of Pennsylvania have placed the ideal size of a knowledge worker team at five. This means that if you are looking for the ideal size for your teams, around five members per team would be a great place to start.
But size isn’t the only consideration for building an effective team. You must also consider the mix of skills that will be present on that team. Successful small teams are structured in such a way that they are cross-functional and have the right mix of skills necessary to deliver an increment of product with minimal dependencies on other teams. For example, if your team’s delivery flow includes designing a compelling UX for your product, writing the code to realize that UX, and then validating that the entire experience works as expected, then your team should have UX designers, engineers, and testers all committed as part of the team. This will allow the entire increment to be created and delivered without the need of enlisting the help of external teams. This not only increases the team’s sense of ownership over the work they are delivering, but it also allows each individual team to operate more independently within the organization.
Finding the right size for your team can be a daunting task. Many factors can come into play, including the amount of work that’s defined and ready for your team to tackle, the mix of skills available on your team, and the steps your team must take to ship your product. But by keeping each of these challenges in mind while you structure your teams, and erring on the side of smaller teams, you’ll be sure to find the perfect size for your team.
Jeremy Jarrell is an agile coach who helps teams get better at doing what they love. When he’s not mentoring Scrum Masters or Product Owners, Jeremy loves to write on all things agile. You can read more of his thoughts at www.jeremyjarrell.com, see his videos at Pluralsight, or follow him on Twitter @jeremyjarrell.
Category: Productivity
