“let’s look at how the Scrum Guide defines the role of a Scrum Master”

The quote from the Scrum Guide is how the SM role is defined today. It has changed many times — perhaps in response to criticism.

The best SMs I have known took an interest in the work of the team — one even getting an AWS certification. You cannot be an effective facilitator if you don’t understand the team’s work.

Let me start over: the best team lead I have ever known, who ran the most effective teams I have ever been on, was a technical manager named Carl. He was a natural servant leader. He did not make all the decisions for the team, or tell people what to do. He made it his business to know what every individual was working on every single day, and he would bring people together for ad-hoc discussions about issues that he felt were being overlooked. And sometimes he would make a decision, and take ownership of it, and people trusted him because we all knew he was not one of those political managers: he was trying to make us all succeed — not trying to look good.

He was very technical — he made it his business to be. He had a PhD in linguistics, but taught himself computer science by writing “each kind of major program”: he wrote his own operating system, his own database, his own compiler. He read “The Dragon Book” — the definitive source on compiler writing. But he was not the “smartest person on the team” — he was merely the one in charge, whose role it was to help the team succeed — to guarantee that they succeeded — and that was how he looked at it.

The teams did not wait for him either. There was continual collaboration. There were multiple tech leads of various kinds: we were designing a new language (VHDL), and building the first compiler for it, and so we had two language gurus and a compiler tooling lead. We were always popping in and out of each other’s offices, drawing on each other’s whiteboards. We had private offices, but were all located in one area, within steps of each other. (I recall closing my door often, when I needed to focus.)

This was in the 1980s, before Scrum came onto the scene. We ran a full regression test suite each night, which automatically collected the results and put them into a VAX relational database (I wrote the automation for that). We worked a feature list. And when progress started to slow down, Carl organized a daily 3pm one hour meeting in which we would share thoughts on the design and issues we were having. That was enormously effective, and after a month we did not need the meeting anymore.

Our stuff worked; no one worked late. Morale was the highest I have ever seen. It was Carl’s servant leadership style. And it was Agile in the true sense, just as this is.

Contrast that with a non-technical SM who doesn’t have a clue what people are actually doing.