The Problem with ScrumMaster® as Process Police

This is a common view.  “The ScrumMaster enforces the process”.

In fact, somebody enthusiastically told me this only last week.

It’s succinct, seemingly clear and it’s also close to useless.

Leaving aside that it’s probably a gateway drug to Theory X1, consider the following:

Most Scrum implementations these days are far from “by the book”; in today’s interrupt driven corporate culture, when was the last time you saw a team genuinely “ring fenced”?

And this is the problem – how do you enforce “the process” when the process is so incompletely and informally defined?  Most organisations don’t codify the fact that “Our Scrum Teams can be interrupted whenever we feel like it” and would you want to?

What process are we enforcing here exactly?

And would you even want them to?  (Imagine a ScrumMaster refusing to let Team Member’s attend to an urgent issue in live because that would break the rules?)

And who does the ScrumMaster serve anyway? Scrum as an abstract ideal?  Or the organisation that’s paying their salary?

I say it’s time to ditch the concept of ScrumMaster as Process Policeperson and replace it with the notion that:

A ScrumMaster mindfully considers the intersection of the process and the current situation and makes an informed judgement call for which they take full responsibility.

Afterall, if all a ScrumMaster had to do was “enforce the rules” we’d hardly need a human for the job.

  1. Theory X Management states that people are inherently lazy and thus must be “made” to work.  This is in contrast with Theory Y which states that people are able to enjoy work and thus are capable of being self motivated.  Both Agile and Lean are  strongly based on Theory Y – and thus having ScrumMaster’s that subscribe to Theory X thinking is deeply problematic if you want to get the best out of Scrum.