Do I Need to Be a Developer to Be a Successful Scrum Master?

This is a question that has been the agile elephant in the room since I started out as a Scrum Master. People often question, ‘How are you able to effectively coach a software development team without being an IT expert?’ I like to challenge the assumption made here by asking, ‘Why would a software development expert be a better coach to a team, considering these two roles require vastly different skill sets?’

The dilemma is obvious. Given the limited time an individual can realistically dedicate to learning and growing, it is simply not feasible for everyone to become an expert in multiple fields. As a Scrum Master, my education and expertise centered around leadership and people management with a focus on coaching. As a result, full-scale IT knowledge has not been my key strength. Similarly a developer’s strong suit lies in the depth of technical expertise, but this is seldom coupled with the necessary leadership knowledge and management training.

So how do we start bridging these gaps?

For me it boils down to cultivating mutual understanding and respect for each other’s strengths, as well as focusing on building a collaborative way of working. With this in mind, I’m going to take you through my learnings from the past few years which have helped me gain the necessary technical/development knowledge to be an effective Scrum Master while maintaining focus on coaching/team development.

Master the language

I am not referring to programming languages here. However, if the terms frontend, backend, automated tests, nightly builds, CI, CD and DevOps don’t ring a bell, you probably need to ramp up your tech vocabulary. You will encounter these terms and acronyms daily and people will expect you to understand the fundamentals. There is no need to understand the technical implications in detail but you definitely need to be able to communicate and make sense of the context in order to operate effectively and establish your credibility as a coach. This is a process that cannot be fast tracked. Build a glossary of terms and give yourself time to master the language of software crafts(wo)manship.

Read, a lot

There is an overwhelming volume of material related to software crafts(wo)manship available online, so where do you even start? There is no single correct answer to that. Just start googling, reading and researching as you encounter new terms. The first article I stumbled upon by Martin Fowler (highly recommended) was around the topic of Continuous Integration. I tried to make sense of it with my very limited knowledge and I ended up reading through it at least three times. Every time I read it, it made a little more sense.

Practice vulnerability

I’ve had to ask my fair share of “stupid” questions (still do!), which inevitably led to a feeling of embarrassment and even shame. For me, the only possible way out of this destructive pattern, was to 1) acknowledge how I felt and 2) interrogate the root causes of my strong emotional reaction. Our society endorses people who portray themselves as having the answer to everything (even when they don’t). This leaves little space for people who are unsure or need further explanation.

Having identified the destructive pattern I’d been in since school and throughout university, I was able to see how it was harming my own growth which in turn stunted my team’s growth. I embraced my discomfort and vulnerability, and started asking more questions. I got our developers to sit down with me and explain the basics, the infrastructure and the big picture of software development. And guess what? They were more than happy to share their knowledge with me. It was only through conversations with the developers on my team that I was finally able to connect the dots and gain the value I needed from the content. There was no room for shame anymore, only for growth.

Actively build your confidence

If you’re looking for an easy walk-in-the-park role, this is not it. People will question your abilities and you need to get comfortable with that. Some may still be convinced that you need to be a developer in order to coach a software development team. You need to accept the range of opinions out there and that constructive disagreements are always better than artificial harmony.

In hindsight, when I was feeling insecure I put too much energy into proving my point; energy that I could have invested more wisely. My experience has proven that you need to consistently nurture a strong belief in yourself and your abilities to avoid these kinds of energy traps. Building confidence doesn’t happen in a vacuum — it needs persistent reflection, positive reinforcement and it is only effective when it is paired with internal affirmation of yourself.

Stay curious

My passion is and has always been to connect the dots and create the big picture. By nature, I am a curious person and therefore I decided to give software development a try in my free time. It is easy to enroll for a beginner’s online course and that’s what I did. I’m a visual person, so I decided to start with HTML5, CSS and JavaScript and guess what? I love it. Why? Partly because it gives me a sense of achievement but more importantly it broadens my perspective and helps me to get better at asking the questions that will support my team’s growth. Growth that would not be possible if I were to simply tell them what to do in order to solve this or that problem. It is only through asking the right questions and letting them fill in the gaps on their own that I can be the coach they need.

While some people explore the Scrum Master role with prior experience in software development, others may have a business degree and others still may (quite often actually) have their roots in project management. Regardless of your experience, chances are you will be missing a puzzle piece or two.

In order to succeed at the job, understanding the big picture is the key. Finding those missing puzzle pieces and filling in the blanks is going to take time. It’s not always going to be easy or come naturally without making significant investment, but whatever your areas of growth might be, my advice for every Scrum Master is: stay curious, keep asking questions and embrace the fact that there is always something that you don’t know.