All Things Agile - Episode 003 - Use of Overtime

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