Scrum Notes 2013-20

A New Pair of Glasses In this series I challenge some of the misinformed and myopic statements I've heard people make about Scrum over the years, with the intent of clearing away much of the nonsense, confusion and even antagonism that surrounds this very simple, elegant and effective method of working.

Blindspot #3: The Scrum Master is a Code Coach

There is a myth doing the rounds (again!) that a scrum master should coach developers on how to write better code, limiting the scrum master role to a technologist, and worse one that is assumed to be superior in skill and knowledge to the other members of the scrum team. This is the scrum-master-as-tech-lead anti-pattern.

The Scrum Guide mentions the word coaching only three times.¹ Twice in the context of the development team, and I quote, "The Scrum Master serves the Development Team in several ways, including: Coaching the Development Team in self- organisation and cross-functionality [and] in organisational environments in which Scrum is not yet fully adopted and understood" Nothing there about writing code, nor even having such skills at all.

On the other hand, such coaching is not explicitly excluded, and in fairness the guide also says that the scrum master is responsible for "Helping the Development Team to create high-value products" which could perhaps imply writing code and raising the code quality. We should ask though whether such help (I might call it interference) is in the best interest of the development team, or in the best interest of the organisation. I suggest it is not.

Let's consider. An XP coach (or tdd/bdd/clean code/etc. coach) should most certainly be able to code, extraordinarily well in fact, and should be skilled in coaching others to improve, to reach and exceed their own standard. Teams of poorly-skilled developers would need that, and need it soon. Code coaching better be a very short-term arrangement though because if developers are unable to write high quality, sustainable, thoroughly-tested code they have no business being in the field of new product development. And meanwhile there is other work to be done.

A scrum master is not a team lead. A scrum master is a scrum master. It's a new role, not something to be forced into an old HR box. The best "coaching" a scrum master can do is to coach software developers into effective work practices and sustainable pace so they can learn, solve their own problems—and write their own code!

And let's remember, not all scrum team members write code. Scrum teams are product development teams. If we expect a scrum master to be a master coder then we should also expect mastery of visual design, information architecture, testing, database administration, copy writing, business analysis and all the other skills a product team might need. And we enter the realm of utter unreasonableness.

A scrum master may have some of these skills, but in this new role there is other important work to do, and again I quote from the 2017 guide, "Leading and coaching the organisation in its Scrum adoption". This is major. This is full time work, necessary, urgent and vital. There is no time to tinker, fun as that might be. The real job of the scrum master is to create the conditions for a paradigm shift.

This broader, braver way of thinking opens up the scrum master role to be filled, not exclusively by ex-coders, but people skilled in human interaction, with perhaps backgrounds in anthropology, sociology, theatre, visual art, communications, politics, complexity science, teaching, social work, counselling, systems thinking and far beyond.

Scrum has the potential to shift corporate culture, but we need to recognise the immense amount of effort, negotiation and navigation required for that shift, and have good, capable, courageous people freed up to do such work.

¹ Mention of the term "coaching" is reduced to twice in the upcoming 2020 scrum guide.