The Scrum Master Role Is a Huge Waste of Human Potential
There were a lot of Scrum Masters and Agile Coaches at last week’s Agile By Example 2014 (Warsaw). Enough that I was surprised by their numbers, in relation to the total number of attendees. I guess the organisers were less surprised though, looking at the relatively high number of sessions focussing on Scrum Mastering and related matters.
During the conference I tweeted:
and some folks found it a tad too cryptic, requesting some expansion / elaboration.
The Role of Scrum Master
It’s my view that we invest the role of Scrum Master – as a given for Scrum teams – with far too much deference and gravitas. I’d go so far as to say that the role is a crock.
As Angel Medinilla pointed out in his excellent session ”Developing Great Scrum Masters”, the role is wholly an invention of the Scrum authors, having zero antecedents and little to zero evidence supporting its alleged value.
Listening to the stories of various Scrum Masters at ABE14, it struck me just how many of these fine folks were and are striving to care for their teams, add value, make a difference to people’s lives, and so on. And more so, how the Scrum Master role itself was and is frustrating them in all these aspirations.
So, when I say the Scrum Master role, both as widely conceived and as generally practiced, is a huge waste of human potential, what I mean is that most people in that role could be and are capable of so much more, yet find themselves – through constant firefighting, running around, chasing people, and so on – buried under a mountain of time-wasting and pointless trivia.
Here’s what the Scrum Guide says in introducing the Scrum Master role:
“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.”
~ Scrum Guide, 2013 version
But, due to the Universal Scrum Master Failure, the raison d’etre of the Scrum Master role – “…helping those outside the team understand…” is invalidated, and the role degenerates into that of a firefighter, or worse, a kind of dysfunctional Project Manager.
Personally, I find the failures of the Scrum Master role – NOT, I hasten to add, any failures of the folks striving valiantly to make it work, even as it cannot – calls the whole Scrum proposition into question. Combined with Scrum’s inherent failure as a local optimisation, plus the equally dire failings of the Product Owner role (which I won’t go into here) I’d suggest the best thing we can do is to throw Scrum onto the garbage heap of history. By all means pick though its bones for the “good bits” like short iterations, early ship-ability, small batch size, self-organisation, etc. – although none of these are the monopoly of Scrum.
Maybe then we can get back to the core issues we all face:
- “How do we make organisations relying on software development more effective?”
- “How can businesses exploit software development for business success?”
- “How can we better attend to people’s needs through software development?” and
- “What is the core purpose of that thing we so glibly call ‘software development’, anyway”?
I guess most Scrum Masters who agree with this post might be asking themselves, somewhat resignedly, “Is there anything I can do in my present role to make things even a little better?” Short of giving up on the whole notion of Scrum Master, is there anything that can be salvaged? From personal experience, I’d suggest taking a look at the Universal Scrum Master Failure and see if there’s anything you can do to address or correct that failure in your corner of the world. If it turns out that your present employer has no taste for that, then you’re pretty much wasting your time. And your potential. Life is too short for that.