Does the Scrum Master have to be a subject matter expert?
More and more companies are agile, or want to be. Many of them choose Scrum as an agile framework and are therefore looking for qualified personnel. In particular, the Scrum Master qualification is increasingly being sought.
Looking at job descriptions, it is noticeable that almost all Scrum Masters have to meet specific professional requirements. A completed computer-related course of study is usually a minimum requirement. But does a Scrum Master really have to provide specialist domain knowledge, or do companies over-restrict themselves in their search with this prerequisite?
I am originally an economist. Some time ago, however, I "changed sides" and became certified as a Scrum Master. So I’m not a native of the subject.
In my first project I supported a team of 15 mobile and embedded developers. As an economist I was quickly confronted with terms that would have forever remained a mystery without Google, both on my part and on the team’s. These, however, were quickly sorted out.
Scrum Master: What does it actually mean?
I ask this question because I’ve focused on what the original role of a Scrum Master is: to make sure that the team understands and complies with Scrum’s rules. This helps to eliminate problems and stumbling blocks, even if these can be quite technical in nature. However, this type of problem is not essential for the Scrum Master. They are supposed to lead the team – but not professionally. This is already stated in the general conditions of Scrum: the retrospective, for example, does not focus on technical implementation, but focuses on the interaction of the team members, the handling of the clients and any possibilities for improvement in the overall process. If I however, as a Scrum Master, become too immersed in the subject matter, this could quickly cause me to interpret my role wrongly and to deal more with technical problems than with the problems of the team.
And when it becomes technical?
We cannot of course hide technical issues completely. If I get asked technical questions I ask the team to put the problem into simple words. This is not just to make it understandable to me – it is at least as important that stakeholders in the sprint review, for example, understand problems that have emerged during the development process, as they are usually not developers themselves. By trying to explain technically difficult problems in general terms, we are able to solve two things: I can help as a Scrum Master, and the developers are able to prepare themselves for presentations with clients and stakeholders.
Expertise is not everything
Should a Scrum Master therefore necessarily have domain knowledge for the role? Isn’t there more to it than good programming ability – for example tact, intuition, moderation and communication skills? In a team that engenders a healthy and relaxed atmosphere this is usually not only easier, but also faster and more efficient. Challenges are tackled more openly and problems are solved successfully. Creating these basic conditions does not require a degree in Computer Science.