I've worked in a couple of different scrum teams, one I even served as a scrum master. There was one common point among all these teams, the scrum master was always or at least used to be a software developer. Then I joined my latest scrum team last summer where our scrum master is a product analyst.
As scrum teams many times include product analysts and testers, this seemed natural to me and I didn't care at all.
Recently I talked to a fellow developer in the team who is also a fellow scrum master. To keep the conversation running, I asked him if he misses being the scrum master. He told me not really, like me he doesn't like the bureaucratic overhead. On the other hand, he added, he liked that he was more close to architectural decisions and discussions.
I felt a bit surprised.
He continued with that usually many of those decisions, discussions are already made by/between the product owner and the scrum master.
I stepped one back saying with a little bit questioning tone that our Scrum Master is a product analyst.
He reassured me, yes, but it should not be the case. The scrum master should always be a developer. On the other hand, in our company, it's usually a product definition analyst, because it's easier to convince them to take on the role.
We definitely had a different experience in the 5 years we spent in different teams of the same company, but that seemed to be only a detail. The more important thing was that according to him, scrum masters should always be developers.
Is it really the case?
I have looked around at different sources and with my opinion incorporated I make an attempt to sum them up.
The role of the scrum master is an important one, the less mature the team is, the important the role of the master is.
Many agree that the Scrum Master role is not a technical one. He should organize and facilitate the meetings. He should remove impediments and make sure that everyone is on the same page.
Indeed, this seems not to be a technical role. It's more about facilitation and being a servant leader.
But the Scrum Master should also coach both the Product Owner and the Team in Scrum values and practices.
And this is tricky part!
Many think that Agile and Scrum is yet just another project management framework.
It's not just another PM methodology.
It's something made by software developers to software developers. According to one of my former coaches, agile without the extreme programming practices is just a big pile of bullshit. The same people who delivered crap before their "agile transformation" will keep delivering the same crap unless they adopt modern engineering best practices.
Can we expect a non-developer Scrum Master to coach the team on pair programming, unit testing, god forbid TDD, etc? Of course, we can, it just doesn't make sense.
On my side, I came to a conclusion that if you want to introduce agile according to how "the founding fathers" at The Lodge At Snowbird imagined it, and you want it to include engineering practices, not just a set of project management principles, then yes, having a Scrum Master who is a competent developer is indispensable.
This article has been originally published on my blog.