If you operate as a Scrum Master in a Technical domain helping teams build digital or software products, you may have found yourself having to consider this question.
Sometimes the Scrum Master is seen as a Team Leader with an implied level of expertise which exceeds the team’s in order for that leading to occur. If you think of the Scrum Master as a traditional leader more than an enabler, it’s easy to see why that makes sense; you have to know what you’re doing yourself to be able to guide others.
By way of analogy, a few years ago I did my basic motorcycle training; 6 first time bikers practising manoeuvres under instruction from a personable guy called Tony. If anyone had asked “Does the instructor need to be able to ride a motorbike ?”, the answer’s pretty obvious.
Tony had to be an expert, advance-qualified rider to be able to teach and to know exactly what to look for in our clumsy and potentially risky bike handling. Tony’s motorcycle skills were razor sharp, unconsciously competent and bang-up-to date.
So by extension, a Scrum Master in a team of coders needs to be able to code, right ? To be able to show the software team how to handle their software machine skilfully and to a high standard.
Well, let’s see.
In that scenario there were specific measurable competencies to be attained. Everyone stayed on the practice yard at 30 km/h until those competencies were met. There was no scope for experimentation or interpretation. We followed the rules precisely.
Secondly, Tony was the only person there capable of instructing his team, and had 100% mandate and focus on doing so. He had no other task to do or responsibility to fill. Leaving us to learn any aspect on our own, or holding a retrospective for us to identify our own improvement and experiment, say with a new way of cornering, was no option.
Finally, there was no safe to fail environment. It was do exactly as he said, or risk injury.
So if the Scrum Master finds themselves in a ‘team leader’ role analogous to this, then yes there might be a compelling argument: the Scrum Master needs to be able to code.
But let’s follow that through. Full stack, or specialist for the product ? To what standard ? Is there an implication they need to be the best coder there – like Tony was the best bike handler ?
What would that do to the team dynamic, the career developers knowing that they’re not quite as good as the Scrum Master ?
If that’s unrealistic – how about maybe just ‘equivalent’ to the developers ? So they can pair or peer review. Sounds fair enough perhaps, but I believe keeping up with the latest coding standards is pretty much a full on activity requiring learning time investment and significant real commercial experience.
So, maybe just passable ? A background in writing code. Historic knowledge. BBC Basic 1986…. I remember that. Am I a Scrum Master who can code ?
Obviously not that far back, but jow long before a Scrum Master waving their only slighly out-dated or partial knowledge around does more harm than good ?
I’m seeing some problems with the idea now.
And what about the Scrum Master’s QA skills, automation, design, user experience, database, business domain, software architecture ? They’ll need a good first hand standard in all of these as well, of course, because writing code is just one task….
Here’s the point. Whilst a competent writer of code would rightly be valued as a skilled operator, if that person is the Scrum Master then they’re not occupying the Scrum Master role whilst doing these other tasks. They’re not empowering, observing, running experiments, facilitating or removing systemic organisational roadblocks.
And unlike Tony teaching us to ride safely that day, the Scrum Master has many more ways to enable the team than through being a dedicated and vigilant instructor. So the bike teaching analogy doesn’t apply after all.
The Scrum Master who can directly help the team out of a coding problem can look helpful and useful in the moment, but at what cost.
In this short talk we discuss this, and what other tools are available in the Scrum Master toolbox to achieve the long term goal of empowered, non dependent teams.
We consider the respect (or lack of) a Scrum Master may find if their domain knowledge isn’t useful enough to hold a functioning conversation with their team, and the importance of allowing sufficient room for great Scrum Mastery to flourish.
Thanks for reading