multiple teams

As a Scrum Master, Can I Work With Multiple Teams?

This is a common question.  People often ask on LinkedIn about how many teams a Scrum Master can reasonably handle, and a breath later, they mention how large their teams are.  Similarly, I’ve had conversations with members of my own organization where I hear, “It’s a small team.  I can’t imagine the team will take much time.”  In each case, I explain that team size is one of the least important factors when it comes to how much time a Scrum Master spends with a team.

So if that doesn’t matter, what does?  What should we evaluate to determine the time spent with a team?  For Scrum Masters with multiple teams, this question is crucial, and that’s the topic of today’s blog post.  I encourage you to jot down how much time is spent in each area as we discuss each.  You’ll see why when we wrap up this blog post.

Organizational Maturity

Is our organization at the beginning of its agile journey?  Or are we several years in?  How many departments in our organization still require a translation layer?  For example, some departments might require an sophisticated Gantt chart or risk register before they’ll assist our team, and we may need to find a way to satisfy their ask.  Also, how autonomous is our team?  Are managers still making decisions for the team and disrupting them with these decisions or with new priorities?  Do we often have to remind outsiders how we do business and then protect the team from distraction?

Even in mature agile shops, time here is still necessary, and it often takes the form of working through organizational impediments or conversations with leadership discussing how the team is performing.  Depending on the situation, we can expect to spend 1 to 8 hours a week here.

 Scrum Master Acumen

How gifted or knowledgeable we are as a Scrum Master plays heavily into our equation as well.   My blog post Am I a Good Scrum Master? digs deeply into this topic, and I’d like to stop here for a moment to make something clear.  It’s not experience that matters.  Experience means nothing if we’re doing all the wrong things.  In fact, I like how Deming puts it:

It is not enough to do your best; you must know what to do, and then do your best.

It’s about learning the right lessons from our failures.  It’s about emotional intelligence and the ability to navigate personalities.  Ultimately, it’s about what I write in Qualities of Great Agile Coaches.  To evaluate the time we’ll spend here, we should also ask ourselves these questions as well:

  • Have I helped solve problems like the ones my team is facing now? If so, I can borrow from previous examples to work through the issue.  If not, well’ll have to experiment our way to the right solution.
  • How prepared must I be for Scrum events? Experienced Scrum Masters are usually more comfortable playing most things by ear.  One exception would be the retrospective, but I find that I spend less than an hour preparing for those.  Newer Scrum Masters would likely spend more.

Depending on the context, we can expect to spend 2 to 10 hours a week per team in this dimension.

Team Maturity

Usually, the largest spend is here. Is the team new to agile or is the group working from a strong foundation of experience?  Are there influential resistors in the team that require a great deal of our time as we coach them privately?  How skilled is our Product Owner?  S/he can often make the cost here markedly more or less.

I have a laundry list of questions I ask myself in this domain.  Use these blog posts as guide posts to get a handle on the cost:

Depending on the situation, we’ll spend between 6 to 16 hours a week per team in this realm.

Time In Meetings

multiple teamsThis is an obvious contributor.  How much time do we spend in team events, Scrum or otherwise?  I’ve even gone so far as to create something like the screenshot here to help organizations appreciate where Scrum Masters spend their time.  It accounts for time in events, time partnering with the Product Owner, time spent coaching team members, and time required being a good organizational citizen.  It differentiates between required and encouraged functions–largely dictated by team maturity–to establish a range.

Noise

The term noise conveys a negative mental image and for good reason.  The less we can spend here, the more we can focus on our primary role.  Much of what we measure in this dimension are elements not related to our role as a Scrum Master.  I mention above being a good citizen, and here is where we account for such things.  How much time do we spend in one on ones with our manager or attending company- or department-level meetings?  Are we also an individual contributors to a team?  Do we have extracurricular responsibilities in the organization?  For each of us, this figure will be different.

Now it’s time to use those figures we’ve been writing down.  How’d we do?  If we have a single team, did the figure come to more than 35 hours a week?  Let’s hope not.  For multiple teams, we should add together each team’s spend in the Time In Meetings, Team Maturity, Scrum Master Acumen dimensions.  We’ll then add these figures along side Noise and Organizational Maturity.  Again, let’s hope it’s less than 35 hours a week.

If it’s greater than 35 hours, what’s being neglected?  Is it a team, the organization, or is it you that’s paying this debt?  How and in what ways?  I don’t ask these questions rhetorically but sincerely.  The value of a great Scrum Master can be difficult to quantify so it’s important to collaborate with our organization to explain our worth.  It’s just as important to explain the cost of being spread too thin.  I’d love to hear your stories of successes or failures in the comments below. Until next time.


Do you want to get notified when new posts are published? Leave your email below.

4 thoughts on “As a Scrum Master, Can I Work With Multiple Teams?”

  1. Great post.

    I field this question over and over again. I find organizations that are new to Scrum repurpose people from other roles as Scrum Masters and then give them as many teams as possible – which is usually 3 or more. Management has a difficult time understanding the value in this role and therefore doesn’t make the best level of investment. I’m not saying you need to go out and hire a bunch of people, but understand what your new Scrum Masters are capable of and invest in helping them reach their potential. In turn they can help your teams. Unfortunately, leadership often ignores that this will take time it will take longer to see the return. On the other hand, you can invest in skilled Scrum Masters and potentially accelerate the transformation which costs more up front.

    I invite anyone who is toiling over this question to read this post, reflect on your guidance and be honest with their answers to your questions. The decisions they make after that is a reflection on their own leadership capabilities.

  2. As with most things in life and as you point out: context is key. You mentioned several relevant indicators. I’ll give a cliff notes version of those I extracted from your post:

    agile maturity
    product owner(s) capability
    scrum master capability and experience (I’d add diversity of experience)
    team size (though you say it’s the *least* important)
    team autonomy
    volume of outside distractions (be it non-team responsibilities, interruptions, etc.)
    meeting time
    noise that saps time from the primary focus of the scrum master

    These are all good aspects to consider. I would add that there are opportunities for scrum masters to explore to mitigate the impact of the load. One in particular: focus. Just as teams benefit from WIP limits, so do individuals. Note that WIP limits do not imply limited number of teams – just a limited number of tasks on a scrum master’s plate at a time. For example: rather than work on preparation for four sprint reviews at one time, take them one-at-a-time and knock them out.

    Having a diversity of teams is a good thing, I think. I’d probably be bored as a scrum master to maintain six highly functioning teams. I’d rather support four teams where one is new to agile, another one midstream, and another two highly functioning.

    1. We agree on all points, especially the part about working with younger and more mature teams simultaneously. 🙂 Thanks for stopping by, Adrian.

Leave a Comment

Your email address will not be published. Required fields are marked *