When interviewing for a new position last year, the topic of whether or not a Scrum Master should have a technical background came up quite often. Despite the fact that the Scrum Guide does not list any technical tasks for Scrum Masters whatsoever, the default assumption seems to be that they must have a technical background or that ideally, they were software developers themselves at some point. In fact, many job listings for Scrum Masters explicitly ask for software development experience.
Still, there are many Scrum Masters who have no technical background at all, and they still seem to be able to support their teams well enough. Or are they even better than technical Scrum Masters?
I think both sides have distinct advantages and disadvantages. A technically versed Scrum Master can certainly help a team, for example by encouraging the team to introduce or reinforce software development techniques like TDD, continuous integration, etc. A Scrum Master with deep experience in software development might be more likely to discover “unspoken” technical impediments plaguing the team. Additionally, the Scrum Master could act as a kind of “free radical” in the development process, picking up some small tasks, filling little gaps here and there – for example by helping write that one last corner case unit test that the team just couldn’t wrap their heads around anymore, by pushing the pixels into just the right place in the CSS when the frontend developers have already gotten tired of further optimizations after staring at the same page for three days, and so on.
For some of the points listed above, many would object that these are not Scrum Master tasks – and while this is a topic for another post, it already points towards a potential problem: Handling these technical tasks could cause Scrum Masters to neglect their actual duties to the team. Especially software development tasks can demand quite a bit of attention (possibly more than initially predicted), and if the Scrum Master picks up a task from the task board, it might be psychologically difficult to place it back, thus disappointing the team.
Also, there is a high risk that the technically knowledgeable Scrum Master will become involved in the planning by interfering e.g. with the estimation process. Ultimately, technically experienced Scrum Masters always have to be careful not to turn into overbearing know-it-alls with their fingers in every little aspects of their teams’ work.
Non-technical Scrum Masters can actually add some highly useful diversity to a team, especially if they come from areas that are completely orthogonal to technical topics, such as psychology, philosophy, social studies, etc. They might be quite well-equipped to deal with interpersonal problems in the team which can frequently pose significant impediments, and they would be seen as more neutral in technical disagreements and especially in disagreements which are technical only on the surface but which are actually based on unresolved interpersonal problems.
One major disadvantage for a non-technical Scrum Master is probably that it is more difficult to discover unspoken technical impediments. Teams often deal with technical problems that have long been accepted as “unfixable”, so they are never brought up in dailies or retrospectives. A technical Scrum Master could help a team to bring these topics back to the surface. A non-technical Scrum Master will have to take the more difficult path of teaching the team how to (re-)discover these impediments (which on the other hand is more desireable as a long-term goal).
An additional issue is that it might be more difficult for non-technical people to be accepted as Scrum Masters by their teams, especially when the teams are not very mature in their agile mindset. In this case, a non-technical Scrum Master will have to put significant effort into continuously educating the team about the services a Scrum Master provides to the team.
I think it is obvious that both technical and non-technical Scrum Masters have advantages and disadvantages. But in the end, it is more important to choose a Scrum Master who has the right servant-leader mindset and who understands agile values. Beyond that, Scrum Masters need to be aware of their specific strengths and weaknesses and they need to actively work to cover their weaknesses, or ideally, to turn them into strengths.
Having said all that, there is one thing that I want to impress especially on non-technical Scrum Masters (though apparently, also many technical people are not aware of this): Software development can (and should) be fun and software development can (and should) be a creative process! As I have said in other posts, I believe that “Development for fun” is at the core of why we do Agile. Agile allows for software development to be a creative process. Many people who have never developed software themselves might have a difficult time understanding this, as a “naïve” understanding of software development is that you tell a machine what to do, and it executes your commands. But software development goes far beyond that, and it is important for every agile practitioner to understand this, and in my opinion, this is far more important than a detailed technical understanding.
AgileEvangelist 