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.


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.


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.

Being a technically adept scrum master: tips and pointers

I have found myself in this position more than once (assuming the role of scrum master while also being proficient in the technical stack the team was using, whilst not being a member of the development team). I have found the following points have helped me distinguish the role apart from that of a developer on the team:

  • Only offer technical opinion if it is asked, and never in a meeting environment - “I don’t mind taking a look at that, but I’ll do it with you after this meeting” allows you to keep the technical development knowledge separate from your scrum master role.

  • Don’t contribute to the stand-up. As a scrum master what you’re doing in your day to day is removing impediments and organising the team. This difference in stand-up representation can go a long way to help reflect the discernible role between scrum master and developer.

  • If a meeting is to discuss a purely technical issue, and one that you do not need to know the details of, then allow the developers to thrash it out themselves in the meeting you organise, and remove yourself from it, to avoid being tempted to discuss implementation of solutions (a role that is specific for the developers in the team).

  • Be aware in meetings of letting discussion go off topic because the topic of conversation is one that is interesting to hear about. This final point ties in with the first one, but I have found that being actively conscious of how quickly a conversation can lose its focus is a great way to ensure that as a scrum master you keep the team on track.