Being a Scrum Master is all about facilitation, so let’s call it what it is

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.

Is it not so that facilitation is at the very heart of what Scrum Masters (as well as Coaches and others) do on a day-to-day basis? I would therefore suggest that we drop the term Scrum Master in favor of “Facilitator.” Or, for those who are fond of acronyms, it can be “Team Facilitator” (TF), or something similar.

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 — the facilitator should not be 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). Worse, 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. Nope.

So let’s try an experiment. Let’s frame facilitation using the same “this more than that” construct that we see in the Agile Manifesto:

  • 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
  • Acknowledging that not everything can be known and working incrementally from that starting point over immutable timelines and feature sets