All Things Agile - Episode 002 - Ideal Team Size

Agile Instructor - Coaching for Agile Methodologies such as Scrum and Kanban

In this episode, I discuss the ideal size for an Agile/Scrum team. It is a frequent question when organizations first begin adopting Agile. I will provide my recommendation based on solid experience and explain the reasoning behind it. I have also added a transcript of the episode below for your convenience. If you have suggestions for future topics, please send an email to [e-mail]. Also, please take a moment to subscribe to this podcast in iTunes using the podcast icon provided on the right.
All Things Agile - Episode 002 - Ideal Team Size
Transcript:

Welcome to the All Things Agile Podcast. Your destination for tips and interviews with the leaders in the world of Agile. Don’t forget to subscribe to this podcast in iTunes and please check out our sponsor: teamxcelerator.com. And now, here’s your host: Ronnie Andrews Jr.

Hello everyone and welcome to the All Things Agile Podcast Episode 2 Remix. Today’s topic will be ‘Ideal Agile Team Sizes’. But before we begin, quick reminder that this podcast is for informational purposes only and accepts no legal liability. So let’s get started.

For the context of this episode, I’ll focus on Scrum, since it’s a very popular form of Agile. We’ll cover other implementations, such as Kanban in separate episodes. That being said, Ideal Team Size is a popular subject and many newcomers ask about team sizes when they’re first learning Agile. Corporate leaders also struggle with the topic when they try to roll out Agile and form team in their organization.

People are curious how big is too big? Or how small is too small? What are the implications? I’ve often been asked what team sizes do I personally recommend? For Scrum, the longstanding recommendation is 7 team members – plus or minus 2; so that’s 5-9 members. However, the product owner and Scrum Master boost the total count to 9-11. Now, some coaches may or may not include the product owner and Scrum Master when factoring in the team sizes. But I certainly do. So what specific size do I recommend?

Well, based on a hands-on experience across numerous teams, I believe that 10 is a great number to be at. That is 8 team members, plus the Scrum Master and the product owner for a total team count of 10. That is a number that’s in-between the recommendation and one that I have found to be a sweet spot for Scrum teams at many different organizations. If your team, however is too small, it can certainly cause problems.

The reason is that people are wearing too many hats. For example, I do not recommend that Scrum Masters and product owners double up on roles. So for example if you have a product owner or Scrum Master who’s also a critical path contributor on a story, it can be a disaster. So an example would be the Scrum Master working on a story and that story gets in deep trouble and they need to dig deep into it, and then what do they do? So an example would be the Scrum Master working on a story and that story gets in deep trouble and they need to dig deep into it, and then what do they do? Maybe let go of some of their other Scrum Master duties? And then the entire team suffers and other stories suffer.

People need to be able to concentrate on their given role. It’s been my personal experience that if you allow the product owner and Scrum Master to focus on those roles which they should, they’ll be good at them and the entire team benefits because those roles act as multipliers. Now, I especially don’t recommend that the same person serve as both the Scrum master and the product owner. It’s a conflict of interest and I have rarely seen it work out well. Most of the time, it’s also a disaster. It is a constant temptation by business leaders, foolishly trying to cut corners by understaffing the teams. When the team is too small, people may not be able to focus on their core gifts. They also get burned out quickly.

Please remember that one of the principles of Scrum is to build a sustainable, well-functioning team. If you undercut your team, don’t be surprised if you end up with attrition. And I can promise you this: the most talented people will be the first to go, because they have options and they will exercise them. Now, there’s also yet another great reason why you should not shortchange your team size and that’s risk. If you have a small team, it increases your risk profile. If a single team member departs, goes on vacation, has a flat tire, whatever – the team can be in deep trouble. There’s no margin for the team to absorb bumps in the road. If a team is too small, it’s also more likely to have ‘siloed’ knowledge which is an additional risk for the same reasons.

Now, I hope these points have made it abundantly clear that an understaffed team is a bad idea for everyone involved, including the customers receiving the product. Adversely, a team size that is too large can also be a challenge. Simply put, the larger the team, the more coordination is required to provide sanity. In my experience, the effectiveness of a larger team is directly proportional to the savviness of its Scrum master. A talented Scrum master may provide more effective, shall we say ‘glue’ to hold the larger team together.

That said, an extremely large team is still a bad idea. And not one that I endorse. For example, as the size expands, so does the team’s Scrum ceremonies. The daily Scrum meetings or standups become a tiresome chore. It simply takes more time to process so many team members and what they’re working on, which applies to all the team ceremonies. So with very large teams, there’s also a greater risk for destructive conflict. A lack of unity, or cohesiveness. I have seen large teams form factions within the team. That situation breaks down trust and ultimately, destroys productivity.

So why do I recommend a total team count of 10? On average, for Scrum, candidly – it’s a middle ground. It mitigates most of the downsize discussed earlier; there are enough members to reduce risk and prevent burnout. However, there are not so many members that it becomes unwieldy. It’s also a great size for conducting team ceremonies and co-location. It’s very doable to locate the 10 members together, such as a row of cubes or a conference room they can share. In my experience, proximity really does matter. Wise organizations understand this point and make the effort to do so. By keeping people close together, you’ll be amazed at how it improves team communication. And I’ve heard stories in the past about ‘Oh, well we can’t afford to relocate people where they’re sitting because it will cost too much’. That’s simply not true. In fact, it will cost you more money not to, in terms of lost productivity and software quality. It is absolutely worth it to try to co-locate your teams as much as possible.

Now, I won’t say that the team size absolutely has to be 10 members. It’s simply a target to aim for. A rule of thumb, derived from my personal experience, along with the opportunity of watching literally dozens and dozens of other teams in their Agile journey. Selecting a team size at or around 10 will enable the teams to succeed, rather than setting them up for failure. Now, we can’t 100% guarantee success, but we certainly can position the team to win.

That summarizes a few quick points regarding ideal team size. I certainly hope you found them useful. Remember, you can check out my blog using the website agileinstructor.com. Feel free to contact me using [e-mail] and also don’t forget to visit our sponsor: teamxcelerator.com, which makes this podcast possible. It’s a cloud-based Agile team software package, designed for small and large companies alike. Thank you once again for joining me for this podcast, please join me for Episode 3 where we’ll discuss the use of overtime, such as scrambling to meet those crazy deadlines. You don’t want to miss it! Remember – it’s time to accelerate your team today!

Thank you for listening to All Things Agile. We look forward to you subscribing to the podcast on iTunes and leaving a kind review. Thanks and God bless!