Should a Scrum Master Be Technical?

By Barry Overeem

In a couple of short blog posts I’ll share the most common questions I get asked during the 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 Go to the full article.

Source:: Business 2 Community

Be Sociable, Share!