Photo by Shane Rounce on Unsplash

Is Being a Scrum Master Really All About Mastery of Scrum?

I think we should be referring to people working with teams in an Agile setting using a term other than “Scrum Master.” Furthermore, I think such a change is long overdue.

Take for example how much time a Scrum Master might spend on activities that fall under the general heading of facilitation. I would therefore suggest a different term in lieu of Scrum Master.

Here are the main reasons why I am not fond of the term Scrum Master:

• Calling a person a “master” of anything can suggest that a Command and Control mindset is at work — and such a mindset is the antithesis of what is needed. (To be clear, there is nothing wrong with “mastery” in the general sense of the term; it’s great to be good at things.)
• Being referred to as a “master” also tends to conjure up images of things other than servant leadership or self awareness. What teams most often need is a person who simply listens carefully to what is being said, asks clarifying questions when necessary, and helps them arrive at outcomes that they might otherwise have struggled to arrive at without a facilitator being present. And, I cannot stress this enough —a Scrum Master should not be strongly influencing what those outcomes are — they should be helping create a safe space such that there is open communication and collaboration (and yes, sometimes conflict is part of that).
• The words “Scrum Master,” when used together, suggest that the most important thing that such a person is supposed to be focusing on is mastery of a process (Scrum). And in many instances, Scrum Masters (and others) take it to mean that process compliance is one of the most important things, if not the most important thing, that informs how they spend their time.

So let’s try an experiment. Let’s frame it this way, borrowing from the Agile Manifesto values:

• Team communication and collaboration over process compliance
• Shared understanding of what is to be done over fixation on how decisions are reached
• Open dialogue with users and stakeholders over “walled gardens” separating teams from their customers
• Working iteratively over immutable timelines and feature sets