We’ve recently been having many conversations at Velocity Partners about a Scrum Master and the number of teams that they can successfully coach. We have really started ramping up this particular role with several clients, so our coaching staff has been discussing this topic. I want to spend a little time providing some guidance – based mostly on my experience rather than hard data. Maybe it can help you with the conversations you have with your management team.
The Scrum Master Role
The role of the Scrum Master has been pretty well defined in the Scrum Guide, in various blog posts (here, here, and here among others), and in books. The Scrum Master serves three different masters as a servant leader: the Product Owner, the Delivery Team (called Development Team in the Scrum Guide), and the Organization. In all of these areas, the Scrum Master is responsible for facilitation, yes, but for much more – including coaching. This is my primary limiting factor for the number of teams a Scrum Master can work with at any time.
The Coaching Bottleneck
Given that the Scrum Master’s role is far more than just facilitating meetings (which is definitely the predominant view of what they do), actual facilitation isn’t like the limiting factor. And you’re right – the limitation is coaching. A Scrum Master needs a lot of time to coach given their commitment to teams, Product Owners, and the organization. But what is coaching?
I’ve had this conversation with a lot of people. The prevailing understanding of “agile coaching” is that a coach tells a team or person what to do. But as any Agile Coach will tell you, that’s training or possibly mentoring but not coaching. Coaches observe. Coaches recommend. Coaches don’t tell. Coaches don’t instruct. A coach’s job is very passive in one respect but it’s also very engaged. A coach needs to observe how the team and the individual work. Meetings with teams or with individuals create artificial spaces where observations are biased.
Coaches need to watch the team or person in action. How do they operate? How do they collaborate – or not? How do they communicate – or not? And you can’t do that in a meeting room or during a Scrum ceremony. A Scrum Master needs to be able to sit with a team and see how they work and collaborate and communicate. And you can’t do that with a lot of different teams.
So How Many Teams Already?
Okay, okay. Based on my experience, I have the following generalized recommendations. First, new Scrum Masters really should focus on a single team. They’re still learning the role, the responsibilities and, in short, are “drinking from the fire hose” in terms of Scrum and agile. There is so much information out there, a neophyte Scrum Master should focus on a single team only. They’ll need the rest of their time to learn the role.
For good Scrum Masters, and I mean those with some experience under their belt who are lifelong learners and have been mastering not just Scrum but Agile (and Lean) concepts as well, you probably want to max out at two teams. Most Scrum Masters I know fall into this category. But having two teams is still a challenge, especially if they’re not co-located or they work in different product areas. You don’t need to be technical to be a good Scrum Master, but this kind of commitment means you should really shy away from one.
For the top tier of Scrum Masters – people who’ve been doing this for years – I’d still recommend a maximum of two teams. If you’re a Scrum Master for three or more teams, one or more of those teams are almost guaranteed to be ignored for some period of time. As an Agile Coach, three teams is probably the maximum and coaches aren’t doing the other Scrum Master responsibilities. The best Scrum Masters are going to be more effective working with two teams than any benefit you think you’ll gain by giving them three or more. Hire another Scrum Master, please.
As the role is pretty new within our organization, we’re just starting to set the limits for our teams. We strive to keep out Scrum Master to team ratio to two or less and we provide a Guild for our Scrum Masters to collaborate. With a Guild, the onus of asking and receiving help lies with the people doing the role (with some coaching support). But it helps that they’re all learning from each other and hearing and seeing that they’re not alone in this. And the coaches are there to ensure that problems are being resolved in a way aligned to the Manifesto.
A lot of organizations struggle to keep to the 1:1 or 1:2 limitations for Scrum Masters. But if you don’t, you’re likely setting up your Scrum Masters and your delivery teams for failure. And if you’re doing a scaled implementation – say SAFe or LeSS – you can’t run “sprint turn day” with more than two teams. You can’t facilitate for more than two teams in a day. And even with “just two”, it’s still a challenge.
Scrum Masters are critical to any agile adoption, whether team-based or scaled, and the right mix makes all the difference. So be nice to your organizations, your teams, and your Product Owners by being nice to your Scrum Masters. You’ll thank me later.