Don’t overload your Scrum Master!

Aka "Absent Scrum Master Anti-Pattern"

There is a question that keeps cropping up when talking to clients. It is 

“How many teams can a Scrum Master lead?”. 

My answer? Just the one.

Let’s take a closer look at why people persist in asking this question, and try to understand better why it is generally a Bad Idea™. 

When a team is running well, everyone is happy, and product is being delivered successfully iteration by iteration, feature by feature. There is comparatively little for the Scrum Master to do aside from day to day housekeeping. Everyone knows how the process works, everyone plays their part. The system chugs along and delivers. The SM appears to have a huge amount of slack, which most organisations believe is a Bad Thing - slack means they need to squeeze out more performance (read “profit”), in this case by giving the SM something else to do. I.e. another team. And maybe another. And another. Or other random responsibilities. Ignoring the bad consequences of such task-switching, the organisation can get their diary looking something like this:

(I should add that this is a real calendar. I worked with the SM, so I also know that none of the time bookings were related to the main team he was trying to serve)

What you end up with is a system that is at maximum capacity. Which is fine - as long as nothing changes, and nothing goes wrong. A common analogy is having all cars on the motorway driving flat out, bumper-to-bumper. What could possibly go wrong?

A multi-team Scrum Master will not have his full focus on any of the teams. So small problems go unnoticed, or worse still, noticed but uncorrected due to time pressure elsewhere. Perhaps lacklustre delivery, a few bugs appear that are ignored, internal friction in the team. All easy to nip in the bud if caught early. But these kinds of problem tend to grow and multiply if left unchecked. So suddenly a small issue leads to a major pile-up. And all because the Scrum Master was trying to interact with more than one team. As a side effect, while the SM is trying to recover the situation in one team, he will be neglecting the others. And suddenly he is playing a dangerous game of Whack-a-Mole trying to keep all the teams running smoothly. Needless to say, this behavioural pattern often fails.

Finally - coming back to the slack experienced by a team-monogamous Scrum Master during the fair-weather delivery periods. What to do? It is a fair question. My advice is simple. By all means use some of the time on other tasks. But these are entirely secondary. Non-time-dependent "optional extras", if you will. The moment the team needs more time from their SM, all other tasks are dropped and the team needs become the number one priority. No question, no penalty, no punishment (e.g. because secondary xyz wasn’t delivered).