Being a Technically Adept Scrum Master

How to be a Technically Adept Scrum Master without being a Developer

In agile process the role of a scrum master is defined as:

The scrum master is the team role responsible for ensuring the team lives agile values and principles and follows the processes and practices that the team agreed they would use.

The responsibilities of this role include:

Clearing obstacles.
Establishing an environment where the team can be effective.
Addressing team dynamics.
Ensuring a good relationship between the team and product owner as well as others outside the team.
Protecting the team from outside interruptions and distractions.

This is clearly an important role in the agile / scrum process. Anecdotally the role is in a bit of no man’s land. A scrum master is not supposed to be a position of management, or a person who “runs” the team, but simply a mediator, someone who ensures process is completed and keeps the conversations streamlined. If you have a stand-up and it devolves into a conversation between a few select members of the team rather than an update everyone can understand, the scrum master’s role at that point is to realign the conversation, and refocus the meeting, as a good example.

Perhaps not so obviously, the points and responsibilities listed so far for the role of scrum master are all particularly non-technical and revolve more around organisational and people skills. So that poses a question I’m hoping to answer, or at least to talk through: Would you be better having a technically adept scrum master? The short answer, in my opinion, is that having a technical scrum master can be a bit of a double-edged sword.

Pros

The obvious advantage of having a scrum master with technical capacity (that is, the knowledge needed for the technical work being completed) is that any conversations can be followed more easily. If a scrum master can follow the conversation technically, it becomes a lot easier to interject and restore the conversation back to the intended purpose (as we all know, passionate devs can very quickly go off-topic). They can also pose questions that need answering that may have been missed by a non-technical scrum master, with regards to ensuring outside distractions are handled and the effective environment is established. If a technical obstacle exists, an adept scrum master will be more capable of explaining the obstacle and hence (one would expect) can remove the impediment in question in a timelier manner.

Cons

An often-overlooked element of the scrum master role is that it is supposed to be a relatively removed role from the team. The role is that of a facilitator, and it could be considered that a good scrum master is very rarely actually noticed, particularly if the team has good agile principles to begin with. This facilitating-but-hands-off role can be harder to maintain for a scrum master who is fluent in the technical language and passionate about the work being done. If the scrum master is more adept at the language in question, and can see a solution to a problem the team has that the team has missed, would it be considered bad practice for them to suggest this solution, or could they consider this part of the obstacles that it is their job to clear. I leave that as an open question to the reader. The risk of stand-ups becoming very technical rather than a generic update is also increased, if the scrum master is a willing participant in said discussions.

So, is it better or worse?

It’s a hard question to answer. I think, as cliched as it sounds, my answer is: it depends! A technically adept scrum master who is capable of ensuring they are still acting correctly as far as the role is defined, who can understand systems and explain obstacles in the correct language without much assistance from the team, is what I would consider to be the “ideal” scrum master. However, if that technical capacity comes at a cost of the crucial main responsibilities of the role of the scrum master, then the agile process for the team, and hence the business value of the team, will suffer.