Here’s a topic that will likely be heavily debated by different Agilists and management-types alike. Which is better for your team? A technical or non-technical Scrum Master? Let’s first clarify what it means for a Scrum Master to be “technical”.
From my experience, most teams that utilize the Scrum framework are assembled to build something, a product or a service, usually using some kind of tools (i.e. technology) to get the job done. The end product will likely involve a combination of the following components: software, hardware, systems, modules, etc. So, for the purpose of this article, technical knowledge refers to domain knowledge of the underlying system, tools, and/or processes that contribute to the design, development, testing, and/or delivery of the product. Okay, that was probably slightly confusing.
The debate regarding whether the “best” Scrum Master must possess this knowledge of the domain/system is really a debate about what the Scrum Master needs to do in order to be effective for the team. If the team needs the Scrum Master to also be a contributor to team deliverables and tasks, then it’s easy to state that this person must have the necessary technical know-how to be successful.
On the other hand, if the team requires the Scrum Master to be a facilitator and coach for the team in terms of applying Scrum in the most effective way, it can be argued that this person does NOT require technical knowledge of the end product. Some may disagree, stating that the Scrum Master would not be effective without some minimal understanding of the technology.
My experience with this situation is varied, but generally speaking, I personally prefer the latter scenario of having a “dedicated” Scrum Master who does not contribute to the end product. My rational for this is that I value focus more than someone who can context-switch between being a facilitator and a contributor, which usually leads to a conflict-of-priorities, especially towards the end of a Sprint when the clock is about to run out. Having the ability to focus on serving the team maximizes the benefit of the Scrum Master.
Now, here’s a slight wrinkle to this scenario – Can the Scrum Master be even more effective if he/she has the technical knowledge which may provide more context into specific situations? My answer is “it depends!”. Sometimes the team may rely too heavily on the Scrum Master to solve a technical issue if he/she is capable, which may actually form a bad habit and stifle growth for the team. From that perspective, it may actually be better for the Scrum Master to have ZERO technical knowledge if we truly wish to cultivate a self-organizing team with a continuous-learning mindset!
So, whether you need (or want) a technical Scrum Master is entirely up to your specific situation, but now you have a few more things to consider before making that decision!