Scrum Master - Technical or Not ?

Lets get the cat amongst the pigeons then :)

We were having a debate in the office today as we adjusted our strategy planing around the 5-Pillars of Digital Evolution (we're not Transforming in my view, we're Evolving what has been Transformed). We were looking at the People and Process side of things and rounded on the best way to build the Sprint teams. Naturally, as people will expect who know me, I was pen in hand on the whiteboard when we circled the Scrum Master.

With an interesting blend of CTO, Head of Delivery, Head of Engineering and Head of Product initially at the board we talked about the role and who should take it on. As our views on the right person emerged we found that we'd rounded on the traditional debate of what the Scrum Master should do, what he/she should be able to resolve and how he/she should resolve it. The results that came out as those in the debate expanded were interesting, I've summarised them below:

Technical People's Viewpoint - The Scrum Master absolutely has to be technical, it's his/her role to lead a team of people doing detailed technical things (code-test under DevOps approach). When things go wrong or get blocked it's a technical requirement to help unblock the problem and you need to be technical to do that.

A PM or a PO can't be the Scrum Master, a PM/PO role is well versed in running the process and ceremonies but it's not able to advise on the detail of the technology (although should have some domain knowledge at the business level)

The Scrum team resources would naturally look to a technical person running the Scrum team.

Business/Delivery People's Viewpoint - The Scrum Master absolutely can't be technical but needs to be technical aware. Therefore it fits better with an Agile PM or someone similar. The rationale being that a technical person is most likely to rabbit hole themselves on technology as they simply can't help themselves and the more leadership/admin side of the Scrum Master role isn't then done right. Result being a failed Sprint or worst case and failing delivery.

The PM or even a PO, that is technically aware, can still debate on things causing a blocker and use the nominate technical expert (senior dev) to help unblock something that is detailed in technology. That though is not the majority of the unblocking that is necessary. The Scrum Master role leans more heavily on process

The debate didn't really reach any conclusion other than there is a general acceptance that the Scrum Master has to have technical capability but it's the depth of capability we were debating.

I have to say I've always argued the point that the Scrum Master is a developer, one that is people aware and doesn't mind the admin side of running the ceremonies and working with the PO on planing and priorities. I'd agree it's likely not the lead developer as you lose the benefit of their expertise and velocity. The argument back on this is:

• Developer that is people aware and a good leader - reducing the selection pool immediately
• Developer that is people aware, good leader and likes to run a process that is essentially a non-technical thing - very small selection pool
• Developer that is people aware, good leader, process lover, enjoys spending time on the business side and focusing on priorities - Unicorn ! Put another way, not a developer

As I said, we didn't reach a conclusion and the debate continues but I have to say I have softened my stance on "must be a developer" considerably as some of those in the debate were able to evidence why it's failed in many places with a developer in role who does too much tech and not enough process.

I'd be really interested in your view, start any comment with your role (developer, tester, PM, PO etc). Would be fun to see if the differing camps out there had a differing view to the office today.