Agile

Should a Scrum Master Be Technical?

In a few short blog posts, I’ll share the most common questions I get asked during the Scrum.org Professional Scrum Master courses. I’ll…

Jimmy Janlen — Agile Topics Card Deck

In a few 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 provide an answer based on my 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:

This blog post will be about the question:

Should a Scrum Master be technical?

By technical, I mean having a solid understanding of the development team's engineering practices and techniques.

In preparation for this blog post, I’ve studied many published articles. I’ll share my journey in the first part, and the second part contains some highlights of the articles I studied. Please read the original articles to understand the context fully.

My Personal Journey

As a Scrum Master, I have worked with many software development teams. Although I’m very proud of the SQL certificate I achieved many (many, many) years ago, I don’t consider myself technical at all. In the beginning, I considered this 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, coding in the evening, and studying the technical side of our products. This was 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 product's technical and in-depth functional parts. This came at a cost. For example, I wasn’t paying attention to team dynamics during the Daily Scrum. My primary focus was on understanding the details and asking lots of questions. Questions that were only relevant to me. I caused the Daily Scrum to exceed its time-box time after time.

Slowly, I discovered that some technical (and functional) knowledge was useful. However, the Development Team appreciated my coaching and facilitation skills—asking powerful questions that offered them a different perspective on solving difficult problems. They often discovered the solution by letting them explain technical issues to me. 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 to 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 who was able to help create some awesome Scrum teams!

Other Opinions

Ebenezer Ikonne

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.”

Geoff Watts

Source: Scrum Master — should they be technical or not?

“Of course, some Scrum Masters benefit from a little technical knowledge in developing rapport, asking more insightful questions, and having a stronger “spidey sense” of knowing when something isn’t right. However, I have also seen that technical knowledge becomes 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 to solve their 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 organization 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: software development. Of course, a technical background is a plus. The best testers, PMs, 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 kinds 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 (full-time) 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 full-time Scrum Master. Although he fulfilled the role full-time, 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. He discovered that also within a Scrum Team there’s a lot of opportunity for personal growth (because that was the main reason for 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 in fulfilling the Scrum Master role. However, be aware of the pitfalls I’ve described. Most of the Scrum Masters 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 asking 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.