Is the title “Scrum Master” a bad idea?

Some questions regarding the role of the Scrum Master and the blurry lines between the roles of Scrum Master and Agile Coach.

Note: quotes are from the Scrum Guide, unless otherwise noted.

All illustrations © 2019 Carlos Pires

Question #1: Shouldn’t “Scrum Master” be instead “Master of Scrum”?

For sure, “Master of Scrum” sounds awful and I’m not proposing to replace “Scrum Master” with “Master of Scrum,” but after reading the Scrum Guide you might come to the same conclusion as I have: a “Scrum Master” is supposed to be, first and foremost, a “Master of Scrum.” The Scrum Master is on a never-ending quest to master Scrum, and he is the one who helps other people also master Scrum.

“The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.”

But “Scrum Master” always sounded to me as prone to multiple interpretations. For instance, it can be interpreted as “Master of the Scrum Team”. I have encountered this misinterpretation way too many times for this to be regarded as an exceptional mistake. For starters, people new to Scrum usually presume that the Scrum Master is someone who tells others what to do. And I have also heard different versions of this misinterpretation from people who have actually read the Scrum Guide.

There is always the risk of being misunderstood when you try to use a word that has mostly been used with a different meaning for centuries. Doesn’t the word “Master” pack a cluster of meanings that is in itself incongruous with the values and principles of Scrum, namely self-organising teams?

“(…) Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. (…)”

My interpretation of Scrum leads me to believe that in the Scrum Team nobody should have a master other than the Scrum Team itself. Not only the “Scrum Master” is nobody’s master, but he is actually a servant of the people in (and around) the Scrum Team. Furthermore, though the Scrum Master is a “Master of Scrum,” he is bound by the limits and precepts of the Scrum framework. So, he is a Scrum Master but not in the sense that Jimmy Hendrix or Stevie Ray Vaughn were Guitar Masters: if you are a Scrum Master and you try to play Scrum with too much distortion or vibrato… then you might not be using the Scrum framework anymore!

Are you a Scrum Master of the Universe?

Question #2: Can a servant serve more than one master?

The Scrum Master is a “servant-leader” because he is the one in the team who is assigned to be the “Master of Scrum”: he is a leader in the sense that he is a guide, for he is the one who leads the way towards a better use of the Scrum framework; and he is a servant in the sense that he services the Product Owner, the Scrum Team, and the Organization in every way he can in order to maximise the value delivered through the use of the Scrum framework.

“The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.”

Now let’s say you are a Scrum Master in 3 different teams, working on 3 different products. How do you schedule ceremonies you must attend in multiple teams? What happens when there are conflicting needs from different teams? How can you possibly provide the highest value to your team, if you have to put your own interests (e.g., your schedule) above those of the teams’?

It looks to me that this makes no sense whatsoever. And the matter gets even worse if you are a Scrum Master for different teams in different organisations. If the Scrum Master is to be a “servant-leader for the Scrum Team” and if no servant can serve more than one master, then the Scrum Master should not be working in more than one Scrum Team at the same time(i.e., for the duration of the whole project).

Process over people

Question #3: Are Scrum Masters erasing the fine line between “People over process” ?

I’ve heard about professional Scrum Masters who work on different teams and who bring to those teams certain practices devised to elicit more collaboration from all team members. It might be, for instance, some kind of parlour game to be played during a Scrum Retrospective with the aim of getting people in the Scrum Team to share their views more openly. This kind of thing might be an instance of what the Scrum Guide mentions as helping everyone change their interactions in order to maximise value, but… is it really?

I like the Agile Manifesto because of the values it espouses but also for the very concise and clear way in which it expresses those values:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Notice that the first thing the Agile Manifesto claims to value is Individuals and interaction over processes and tools. This precept is often abbreviated to the simple motto “People over process”. This points to a very simple way of determining if a tool or a process should be adopted by an Agile team:

1. if people don’t want to use a process, then don’t adopt it.
2. if there is a way to accomplish the intended result without adopting a process, then do it that way.

Now think about it: should we really be making people play parlour games in Scrum Retrospectives? Can’t the same result be accomplished by other means? Shouldn’t we rather be helping people overcome any obstacles they might be facing before the events take place? Isn’t that one of the things the Scrum Master is supposed to do? Actually, I’m sure some Scrum Masters will say they don’t have the time to do this kind of work because… they work with more than one team! (QED, question #2)

Sure, there are situations in which you really need some form of “game” or set of rules in order to steer group dynamics so that you can ultimately accomplish your goals. And sure there are teams who can enjoy and benefit from using these processes. What I’m trying to say is that Scrum Masters probably should be aware that this might be tipping the balance of the “People over process” precept, which in turn is the foundation for all the qualities required for an autonomous, self-organising team.

Furthermore, such rule-imposing practices (however informal they might seem to be) effectively establish the Scrum Master as someone who dictates rules others must follow. This seems to me as detrimental to the culture of individual empowerment necessary to foster self-organising teams.

To sum it up…

Though I understand it might be impossible, I do wish we could find a better word than “Master” for the “Scrum Master” title. IMHO, it spawns too many misunderstandings.

I also understand the reasons for having Scrum Masters work with multiple teams at the same time, but I am sure you will get better results if you get a Scrum Master for each team. According to the Scrum Guide, that guy can’t be the Scrum Master, so I suggest you call him Agile Coach and empower him to not only work with different Scrum teams, but also with the whole organisation.

And yes: you should do whatever fits you and your team. Just don’t forget to put people over processes!