Should a Scrum Master Be Technical?

(Netherlands)

August 30, 2017

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:

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.

What did you think about this post?

Share with your network

Comments (13)

Sarah Smith

05:38 pm August 31, 2017

I struggle with this too sometimes. I love the examples of the three technical scrum masters. Technical experience to a small degree has helped me, but being knowledgeable enough about the processes and the tools the team uses, the scrum master can give some insight that the team may not have thought about. Thanks for the insight!

ScumMaster

11:57 am September 1, 2017

Yes, he should. Anything else is fronting, cool trendy words and mindless 'brogramming'. You are actually an impostor, sorry.

Benjamin Feireisen

02:23 pm September 1, 2017

Well, in my personal experience and by discussing with many (over 100, I stopped counting :P ) other devs, is that the best Scrum Masters were those with no technical background, BUT extremely open to understanding and learning it.

ScumMaster

03:12 pm September 1, 2017

Open-ness will not get the job done, nor give accurate estimates to management and or the client. Not saying that other-than-tech skills dont matter, just that over optimistic yay go team scrum planification usually only serves to deliver flawed software, if in time at all. Give me a good old project manager and a good functional analyst, and we will get any job done. Agile should be about removing impediments, not adding them in the shape of lay people. Give me an open, optimistic SM that doesnt know tech, and an equally non-tech PO, and we have spelled disaster and burnout for the developers. Sorry but this is my (sad lol) experience after being part of many, many scrum teams. But then again, it may be just me and my negativity 😜 Dont even get me started on imaginary deadlines and useless ceremony, thats for another post lol

Benjamin Feireisen

03:57 pm September 1, 2017

It's not that I disagree with you (you raised some great points :) ), it's just that there's a fine line between comparing what is comparable. Give me a great polyvalent dev team, with a facilitator who is here to ask the real questions (eq. facilitate) and a P.O. who communicate, and we can overcome everything, even the hardest of clients. Which is now comparable to the good old project manager and analyst :D The burnout from the developers usually (not always, obviously !) come from the misunderstandings of the roles, and how to implement it. Way too much have I seen Scrum Masters who dedicate themself to dev part of the time, and forget the big picture to protect his team, and a PO who commands everyone to get what he wants in the next sprint, even if the tasks are way past the velocity. That killed too many projects. It's still the same problem, we're all human. And here I go with my own negativity :P Also, agreed with those imaginary deadlines, and also this : "Hey we estimated that we can do that in 3 sprints so there is your deadline" "Wait wat no it's an ESTIMATION not a DEADLINE"

ScumMaster

04:54 pm September 1, 2017

Yes, i guess it is exactly that misunderstanding of the SM and PO roles which contributed making miserable every scrum team i have been part of.... But still i am convinced that a little technical insight by their part would have saved us many, many disasters and much stress. Agile was born by and for developers, to make things flow more easily, not playing card games and so and so 😝

Kate

07:35 am September 4, 2017

For me being a Scrum Master with some technical background is more then helpful. I understand theirs problems, I'm not lost in all the techie words and still can ask some questions. I had that bless that was working in a great scrum team as dev and understand the other side. You understand what is the most important part for you as a Developer which in contrary is more then often sth else then having perfect scrum :D Let's face the truth if the team for instance have tone of legacy code, poor quality and in addition they new team - building the team is one case but understanding what;s the most important for them and giving necessary room for improvement and decision (because you understand the purpose) is sth different. So having technical background is definitely helpfull and not necessary to achive success with the team!

Julian Bayer

01:01 pm September 4, 2017

Is it the ScrumMasters job to give accurate estimates to management and/or the client? I don't think so. ;-)
I do agree that my technical background has helped me coach the team I have now. But really, I think it depends a lot on the team.

ScumMaster

01:19 pm September 4, 2017

Not explicitly, but either he is an important part of that decission process and to reach consensus if it is done right, hence it is part of his job, or either he is in a bastardized version of scrum in which a team leader disguises his role as scrum master, as we spoke above, and then it is also part of his job. Also, who do you think management will come to looking for estimates and so on? To the devs or to the guy with 'Master' in his title? 😂

So i still think yes 😁

Julian Bayer

06:20 am September 5, 2017

Why is a non-development Scrum Master an important part of the estimation decision process? He literally has no business with estimation other than facilitating it and - if necessary - remind people how estimates work in an agile environment. Neither of that involves any technical skill whatsoever.
Estimates are given by the development team and the development team only. Both the Scrum Guide and the agile manifesto are crystal clear on that one. So I don't know why you think the Scrum Master needs to have technical skills for estimation.

As for who the management will come to looking for estimates? I would expect them to go to the Product Owner, seeing as he is in charge of the Product Backlog. The estimate is an attribute of a Product Backlog Item, hence part of the Backlog. He's the person responsible for the product strategy. Thus, he is the one who can give the kind of high-level estimates Management is looking for. If Managers are asking the ScrumMaster (or anyone, really) for estimates on PBIs, then I'm sorry, but they're micro-managing (and even then, the PO should be the micro-managers go-to-guy on this).

Still, it doesn't really matter who Management asks for estimates, because no matter who they ask, those estimates will always be the same. It's the estimates the development team gave. Again, no technical expertise needed on the part of the person being asked.

Koti Reddy Bhavanam

05:58 pm October 8, 2017

It is not a mandate but from my experience it was useful in addressing some of the impediments which are beyond the self organisation of the development team.

Huy Chau

11:31 am August 1, 2018

I used to be a part-time Scrum Master / QA Automation Engineer but now full-time Scrum Master. In my situation, single team Scrum Master with some sort of technical background and understanding is useful for Scrum Team.

First of all, I do understand how the product under work is being built with high level of understanding from different components/services. Enough knowledge that does not enforce me to look deeply into developers' codes to find optimum ways to write. Having some related technical knowledge gives me opportunities to unblock my team's impediments by finding correct solution from cross-functional teams. This is also an advantage to take when there are discussions with Management group and convert technical topics into more understanding contexts.

Secondly, if you are a multi-team Scrum Master, having technical knowledge is also a plus. But, you simply do not have time to efficiently take advantage of your technical knowledge as Scrum tasks are fulfilling your daily hours.

lion575a

10:27 am September 9, 2022

Scrum masters should be developers and also very familiar with the project. If they are not they are a major hindrance, or not really doing most of the responsibilities of a scrum master.