In a couple of short blog posts I’ll share the most common questions I get asked during the Scrum.org Professional Scrum Master courses. I’ll focus on the Scrum Master role and will provide an answer based on my personal experience as a Scrum Master. This for sure isn’t the ultimate answer, it’s how I’ve fulfilled or experienced the situation myself. I would love to learn from your experiences as well!
As part of this series I've already shared my view on the questions:
- “Can you be a part-time Scrum Master?“
- "Can you rotate the Scrum Master role?"
- "What is a Scrum Master actually doing during the day?"
This blog post will be about the question:
Should a Scrum Master be technical?
With technical I mean having a solid understanding of the engineering practices and techniques the Development Team uses.
As a preparation for this blog post, I've studied the vast amount of already published articles about this topic. In the first part I'll share my personal journey, the second part contains some highlights of the studied articles. Please read the original articles to fully understand the context.
My Personal Journey
As a Scrum Master, I have worked with lots of software development teams. Although I'm very proud on the SQL-certificate I've achieved many (many, many) years ago, I don't consider myself technical at all. In the beginning I considered this as a problem. I felt like an imposter. What is my added value for this team? How can I fix impediments for them? How can I coach them if I don't truly understand the technical practices they're using? Who am I to increase the costs of this Scrum Team with my salary?
For a while I tried to solve this imposter-feeling by exploring XP, doing some coding in the evening, and really studying the technical side of our products. This was definitely time well spent. It's valuable to understand the basics of e.g. XP, DevOps and test-automation. But only to a certain extent.
It took me tremendous effort to understand the technical and in-depth functional parts of the product. This came at a cost. For example, during the Daily Scrum I wasn't paying attention anymore to team dynamics. My primary focus was understanding the details and asking lots questions. Questions that were only relevant for me. I caused the Daily Scrum to exceed its time-box time after time.
Slowly I discovered that some technical (and functional) knowledge was definitely useful. However, what the Development Team really appreciated were my coaching and facilitation skills. Asking powerful questions that offered them a different perspective with solving difficult problems. By letting them explain technical issues to me, they often discovered the solution themselves. In these "conversations" I sometimes don't have to say a single word.
I started focusing on growing their self-organizing capabilities by encouraging them to solve "impediments" themselves. The problems that exceeded their self-organizing capabilities were the ones I would manage. Due my focus on improving my coaching, facilitating, mentoring, teaching, consulting, managing, problem solving and conflict navigating skills I eventually became a better Scrum Master. A Scrum Master that was able to help create some awesome Scrum teams!
Other Opinions
Ebenezer Ikonne
Source: "Should a Scrum Master be "technical"?
- "I believe the answer is yes but that is only if the Scrum Master wants to be able to help act directly on the software product being developed. Otherwise, the answer is obviously no. I encourage all the Scrum Master’s I work with to be as technical they can comfortably be. As a Scrum Master, the choice is ultimately yours."
Geoff Watts
Source: Scrum Master - should they be technical or not?
- "Even if the problem seems highly technical, there is usually a people element to it and the job of the Scrum Master is to help the people who are facing the problem, identify and then resolve the people element to it."
- "Of course I have seen some Scrum Masters benefit from a little technical knowledge in terms of developing rapport, asking more insightful questions and having a stronger “spidey sense” of knowing when something isn’t quite right. However I have also seen that technical knowledge become an impediment."
- "The best Scrum Masters can move from team to team, from domain to domain and from industry to industry focusing on the dynamics of the team and the individual enabling great teams without the need for domain knowledge."
Martin Lambert
Source: "A Day in the Life of a Scrum Master"
- "I have at times wondered if I am an imposter. Who am I to coach software developers if I don't know one end of Github from the other ? Now however, I'm cool with that."
- "Of course a solid awareness of what I'll broadly call XP practices is essential so I can guide the team to explore these."
- "I believe I can serve a team better in the long term by showing them how to behave so as to solve their own problems, (perhaps orchestrating mentoring time from other technical experts) and working with management to create an environment where their teams can thrive."
Bjorn van den Einden
Source: "Comment in LinkedIn discussion"
- "Organisations that specifically look for a Scrum master with a "strong technical background", do not always understand the true purpose of the role."
- "Yes, it can help, supporting the team to innovate, suggesting new techniques or methods, helping the organisation with Continuous Development, understanding the context of the work to better stimulate autonomy"
- "But to be clear, the Scrum Master doesn't do the technical work, doesn't interfere with technical solutions and doesn't need to teach code standards"
Mike Veerman
Source: "Comment in LinkedIn discussion"
- "In my experience the answer is a resounding Yes. Agile Software Development is about that : software development. Of course a technical background is a plus. The best testers, PM's, analysts and Scrum Masters have such a background."
- "Can you be a scrum master without ? Of course. Would it be better if you had one? Definitely!"
- "Let's take an analogy. I have my PRINCE2 certificates, so in theory I could manage all kind of projects, right? Put me in a construction or pharma domain and my added value drops immediately. Can I manage such a project. Probably. Will my team be happy with my performance? Unlikely."
- "Finding that combination of tech and coaching skills is difficult, but let's not fall into the trap of convincing ourselves all that techie-stuff is irrelevant just because it's hard."
Three Experiences with Technical Scrum Masters
I've worked with many Scrum Masters in my career. Varying from very technical Scrum Masters to completely non-techies. I'll share three (probably common) examples of technical Scrum Masters I've experienced.
- One of the best (fulltime) Scrum Masters I've worked with had a strong technical background. Although she claimed her technical knowledge was outdated, she often surprised the Development Team with some useful (technical) insights. She wouldn't offer solutions, but really knew how & when to ask the right questions. She gained respect from the Development Team which helped her with coaching & mentoring.
- The former Lead Developer. When Scrum was introduced he wanted to take the "next step in his career" and become the fulltime Scrum Master. Although he fulfilled the role fulltime, he kept acting like he was part of the Development Team. This was bound to cause problems. He proved to be the biggest bottleneck in improving the self-organizing capabilities of the Development Team. Eventually he became part of the Scrum Team again and discovered that also within a Scrum Team there's lot of opportunity for personal growth (because that was the main reason of becoming the Scrum Master in the first place).
- The Scrum Master / Developer. Also known as the part-time Scrum Master. Although I understand why some teams prefer the part-time variant, I don't encourage it. Often it causes all kinds of problems. For example: if you’re part of the Development Team it’s more difficult to take some distance. Your role is to contribute as a Developer as well. Because of this lack of overview, you might be missing some crucial information only an observer can notice. For more details and other arguments, check the article "Can You Be a Part-Time Scrum Master?"
These experiences taught me that being technical can be a great advantage fullfulling the Scrum Master role. However, be aware of the pitfalls I've described. Most of the Scrum Master I've coached weren't technical at all. But I might be biased; maybe I get asked to coach non-technical Scrum Masters more often because of my non-technical background...
Closing
In this blog post I've shared my view on the question "Should a Scrum Master be technical?" The answer could have been a simple "no", being technical isn't necessary. However, I tried to give it a bit more context by describing my personal journey (and struggles), the opinion of other experts and three common experiences I've had with technical Scrum Masters.
I thought this would be a very easy blog post to write, but eventually it took me two weeks... Although I've shared my thoughts with you, I don't have the feeling that I've "nailed" this topic... But let's but courageous by just publishing it and ask for feedback! :)
What's your opinion? Should a Scrum Master be technical? Especially if you are a technical Scrum Master I would love to learn from your experiences.