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 [email protected]. 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 destinationfor tips and interviews with the leaders in the world of Agile. Don’t forget tosubscribe 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 AgilePodcast Episode 2 Remix. Today’s topic will be ‘Ideal Agile Team Sizes’. Butbefore we begin, quick reminder that this podcast is for informational purposesonly and accepts no legal liability. So let’s get started.

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

People are curious how big is too big? Or how small is toosmall? What are the implications? I’ve often been asked what team sizes do Ipersonally recommend? For Scrum, the longstanding recommendation is 7 teammembers – plus or minus 2; so that’s 5-9 members. However, the product ownerand Scrum Master boost the total count to 9-11. Now, some coaches may or maynot include the product owner and Scrum Master when factoring in the teamsizes. 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 theScrum Master and the product owner for a total team count of 10. That is anumber that’s in-between the recommendation and one that I have found to be asweet 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. Forexample, I do not recommend that Scrum Masters and product owners double up onroles. So for example if you have a product owner or Scrum Master who’s also acritical path contributor on a story, it can be a disaster. So an example wouldbe the Scrum Master working on a story and that story gets in deep trouble andthey need to dig deep into it, and then what do they do? So an example would bethe Scrum Master working on a story and that story gets in deep trouble andthey need to dig deep into it, and then what do they do? Maybe let go of someof their other Scrum Master duties? And then the entire team suffers and otherstories 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 ScrumMaster to focus on those roles which they should, they’ll be good at them andthe entire team benefits because those roles act as multipliers. Now, Iespecially don’t recommend that the same person serve as both the Scrum masterand the product owner. It’s a conflict of interest and I have rarely seen itwork out well. Most of the time, it’s also a disaster. It is a constanttemptation by business leaders, foolishly trying to cut corners byunderstaffing the teams. When the team is too small, people may not be able tofocus on their core gifts. They also get burned out quickly.

Please remember that one of the principles of Scrum is tobuild a sustainable, well-functioning team. If you undercut your team, don’t besurprised if you end up with attrition. And I can promise you this: the mosttalented people will be the first to go, because they have options and theywill exercise them. Now, there’s also yet another great reason why you shouldnot shortchange your team size and that’s risk. If you have a small team, itincreases 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 marginfor the team to absorb bumps in the road. If a team is too small, it’s alsomore likely to have ‘siloed’ knowledge which is an additional risk for the samereasons.

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

That said, an extremely large team is still a bad idea. Andnot one that I endorse. For example, as the size expands, so does the team’sScrum 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 workingon, which applies to all the team ceremonies. So with very large teams, there’salso a greater risk for destructive conflict. A lack of unity, or cohesiveness.I have seen large teams form factions within the team. That situation breaksdown 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 downsizediscussed 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 agreat size for conducting team ceremonies and co-location. It’s very doable tolocate the 10 members together, such as a row of cubes or a conference roomthey can share. In my experience, proximity really does matter. Wiseorganizations understand this point and make the effort to do so. By keepingpeople 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 relocatepeople where they’re sitting because it will cost too much’. That’s simply nottrue. In fact, it will cost you more money not to, in terms of lostproductivity and software quality. It is absolutely worth it to try toco-locate your teams as much as possible.

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

That summarizes a few quick points regarding ideal teamsize. I certainly hope you found them useful. Remember, you can check out myblog using the website agileinstructor.com. Feel free to contact me using [email protected] and alsodon’t forget to visit our sponsor: teamxcelerator.com, which makes thispodcast possible. It’s a cloud-based Agile team software package, designed forsmall and large companies alike. Thank you once again for joining me for thispodcast, 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 forwardto you subscribing to the podcast on iTunes and leaving a kind review. Thanksand God bless!