The Scrum Master Role is Misunderstood

I have observed a pattern in my Scrum classes: many people have a skewed perspective of the role of the Scrum Master.

To broaden your perspective, it’s helpful to consider a brief history of Scrum.

Organizations that were adopting Scrum 20 years ago were the early adopters. Perhaps agility was in the DNA of their company and they saw Scrum as a set of working agreements that was highly compatible with their work environment. Perhaps Scrum provided consistency in an otherwise scrappy and chaotic startup. Or perhaps Scrum provided them much-needed disruption — a new set of working agreements to disrupt a growing bureaucracy.

Then we saw the early majority adopters. These were companies who saw good results of Scrum so they invited their staff to go to training, learn about Scrum, and bring the ideas back into the enterprise — perhaps to get a leg up on a competitor. Many of my clients through 2015–17 would be in this category. Either they were young companies that found value in adopting some of Scrum’s working agreements, or they were the more innovative departments of large enterprises (banks, telco, insurance) that believed Scrum was a way to infuse new ideas into their I.T. department.

It’s clear that the people currently educating themselves about Scrum are the late majority adopters. Their organizations believe that the people in the job market who advertise themselves as Scrum Masters have a toolbox of “best practices” at the ready. They are likely to believe that these practices are tried and true and, by training or hiring, anyone can apply these practices in their day-to-day work.

I believe there is a systemic misunderstanding of the role of the Scrum Master

I find it helpful to think about the early adopters of the Scrum Master role. Who were they? What was their interest in Scrum? What did they bring to the role?

Imagine, for a moment, a person somewhere between 1995 and 2005. They are in their late 30s, 40s, or 50s. They’ve been a manager of teams for many years. Maybe they’ve started their own company and perhaps successful in a tech startup. They had been writing software for many years. They were deeply experienced. They had already held management roles. They were likely to hold an authoritative position in their company and had influence, if not direct decision-making authority, over the organizational design. When they learned of Scrum and other Iterative & Incremental Development practices, they were naturally attracted to them because such ideas matched the way that they naturally worked.

Furthermore, they had experienced the hardship of negotiating contracts with large enterprises who want certainty of scope, time, and budget. Knowing that the work they do in software development and digital systems management is complex — the end states cannot be known, perhaps these practices provided a language around the difficult negotiations they were having with large enterprises.

These are the sorts of people that would introduce themselves to the authors of Scrum, show interest, learn about the framework, and take the ideas back to their own companies and volunteer to be a Scrum Master.

Maybe they were like me. I was introduced to Scrum in 2007. I had been writing software for 14 years; I had been through a career change; I had held a few jobs from startup to small business; I was a webmaster managing web properties for a large enterprise; I reported directly to the CTO. When I learned about Scrum, I saw it as a way to mitigate risk, to adapt to changing requirements, to focus the development effort on near-term objectives, to deliver frequently, and to interact more directly with users.

So, when we consider the role of the Scrum Master, let’s imagine those early adopters when we consider the phrases we so often hear about Scrum Masters. For example: “Scrum Masters facilitate the evolution of the team.”

Yes! They were experienced mentors. They were keen negotiators. They were savvy investors. They had been developer and Product Manager and owner/founder all at once. And, as Scrum Master, their interest turned to team facilitation and evolution. Or for example: when we say “Scrum Masters remove obstacles.” They were able to negotiate organizational change in order to clear the path for the teams — remove organizational obstacles that get in the way of delivery.

They were people who could embody the values of Scrum: courage, openness, focus, respect, and commitment. Because they had lived it — and they could encourage such values in others by leading by example.

In your own setting, if you find that the Scrum Masters have limited authority, limited scope, limited ability to influence organizational change to dissolve the dependencies that limit your team’s quality and scope of responsibility, it’s helpful to remember the history.

And remember that a 2-day Scrum Master course is the entry point — it’s not the destination. Following a introductory Scrum training course, you are not a master of Scrum — rather, you have studied the role of the Scrum Master and the design of Scrum. It’s time to go and apply it…practice it.