ScrumMaster – Should They Be Technical Or Not?
One exercise that we do in my CSM classes is to explore the responsibilities of each of the three Scrum roles and this is almost always a surprisingly enlightening exercise. One topic that often comes up is whether the ScrumMaster should possess knowledge of the technical nature of the work that the development team is doing.
For many, they might be wondering how we could make a blog post out of this question as, for a lot of people, this would be a “no brainer”. In fact, in many teams, the ScrumMaster is also a member of the development team as well so if they weren’t technical then they would not be able to fulfil their responsibilities as a developer.
The question of whether the ScrumMaster should also be a member of the development team is a whole other can of worms that I will address separately another day. For now, let’s assume that the ScrumMaster is a dedicated role and this person isn’t expected or required to do any actual development. Do they still need to know about the technology, the environment, the practices of the development team?
My opinion is no. Of course, my answer will be biased because I have been a ScrumMaster for teams where I had no idea how to do the job of the development team. Yes, I have a certificate that says I have attended a SQL Server class and one that says I have attended a Visual Basic class but these classes were merely taken to expose me to their world a little more not to give me any practical skills I could use.
How Can You Help Them?
There are two responses I usually get when I tell people this. The first response is “If you don’t know what they are doing, how can you spot or solve the impediments they are facing?”
I’m a big fan of Gerald Weinberg’s Second Law Of Consulting (well I’m a big fan of Gerald Weinberg in general) but his second law states:
“No matter how it looks at first, it’s always a people problem”
No matter what is going on, the root cause is usually to do with people. People implement systems and processes, people (inadvertently usually) cause problems and then people solve them. So even if the problem seems highly technical, there is usually a people element to it and the job of the ScrumMaster is to help the people who are facing the problem, identify and then resolve the people element to it.
ScrumMasters do not need to be technical to do this. In fact it is possible that being technical could be a hindrance as they are tempted to get dragged in to the technical nature of the problem rather than what is really going on. Of course, there is a chance that the problem is beyond the technical skills and experience of the team member. In this situation, we don’t expect the ScrumMaster to be able to step in because then we would not only be expecting the ScrumMaster to be merely technical, but rather we would be expecting them to be THE MOST technical.
In my experience it is often the person with the LEAST technical knowledge who is the most helpful person. What taught me this was a team who I used to work with who had a process in place for dealing with technical problems. They had a cardboard cutout of a person who, when a developer had a technical problem, they would talk to and 80% of the time, the process of just talking it out to a cardboard cutout would spark an idea for a solution in that person.
The great ScrumMasters, of course, are not cardboard cutouts but they do have one thing in common – they are great listeners. ScrumMasters couple this a great questioning ability to be an effective team coach. Questions that help people explore their own situation, question their assumptions, incorporate new perspectives and challenge them to find some forward progress towards a solution. Sometimes the most naïve questions are the best. In fact I once went on record as saying that “every Scrum team should have a five year old on it” because kids often ask the best, most incisive and naïve questions.
I can just hear the arguments of the haters now: “So Geoff…you’re saying the best ScrumMasters are a cross between a cardboard cutout and a five year old?!”
Well, in a way yes…
But anyway, back to my post. The second most common reaction I get when I tell them I don’t know what my team members are doing or how they are doing it.
How Will You Know If They Are Slacking?
If I don’t know what they are doing, surely they could make up impediments or make them out to be bigger than they are and I would be none the wiser.
Yes…this is true…and it doesn’t worry me.
Because I trust people want to do a good job and I believe that if I create an environment where people are able to do their jobs and they are aware of and bought in to the goal of the project then this is not an issue.
Scrum is built on the premise that people don’t need micro-managing – they need freeing up; the view that when given a problem to solve and the support they need to solve it, you will get remarkable results.
Of course, if you don’t agree with this then Scrum is not for you, and the ScrumMaster role in particular is certainly not for you.
Answer The Question Geoff
So having said all that, should a ScrumMaster be technical?
Of course I have seen some ScrumMasters benefit from a little technical knowledge in terms of developing rapport, asking more insightful questions and having a stronger “spidey sense” of knowing when something isn’t quite right. However I have also seen that technical knowledge become an impediment.
In short I believe the best ScrumMasters can move from team to team, from domain to domain and from industry to industry focusing on the dynamics of the team and the individual enabling great teams without the need for domain knowledge.
So if there was a scale of 1-10 where 1 is “no technical knowledge” and 10 is “the most technically gifted and experienced person in the team” I would generally go for something like a 3 or 4 rather than a 7 or 8 but I know there will be many people who would disagree with me on this.
What do you think?