30-04-2024

Hey Reader,

Today I wanted to talk to you about a topic that has been on my radar for the last several months. And the more I look into it, the more I want to discuss it. Luckily, I got a chance to deep-dive into this topic with Mark Metze during the recording of a podcast episode for Agile Within.

The topic is "how much technical knowledge do you need to be a successful Scrum Master (or Agile Leader in general)".

I'm sharing a part of that podcast with my answers to Mark's question in a recent video and blog post "You must be technical enough to succeed in an Agile space".

One of the biggest takeaways for me is that you need to have quite some knowledge about the technical work of your team to be able to help them. And not only technical (even though I don't touch on it in the episode), but knowing product management, for example, is essential when you work with your Product Owner.

My opinion on this changed over the years. And the primary reason for this is the realization I had about my personal journey. You see, I don't have any developer background as part of my career and I don't have a computer science degree or anything of that sort. I often point this out clearly, when I say that even without those credentials I feel that I achieve great results working with devs.

However, while I don't have the 'official' experience, I've always been interested in the tech side of things. I completed an online certificate in Introduction to Computer Science which included coding simple programs. I also made some micro video games that required coding. I often customize my website myself with some coding.

So I don't have tech knowledge, and... I kind of do.

​

​

Why I really wanted to bring it up is that I might have been spreading a bit of misinformation, that, unfortunately, might have hurt our industry a bit.

You see, I would always say that as a Scrum Master, you work with people, not technology, so you need to focus on your soft skills, instead of becoming a tech expert. You don't have to be a developer to be a great SM. You probably going to be a better SM if you are not a developer just because it requires very different types of people to be successful in those roles.

BUT! It might have been taken at face value by some professionals as permission to not even learn anything about the technical work that developers do. And this is not at all the intention I had.

What I wanted to do is to encourage people even without computer science degrees or developer experience to look into Scrum roles as an opportunity for career growth. What I didn't want is to discourage people from learning more about the industry they are working in.

You don't have to be an expert, but you have to understand

Yes, you don't need the experience. But you need to be willing to learn and truly understand how your team works, what kind of challenges they are facing, and what creates complexity in their work.

Otherwise, you will focus too much on the business side of things. Same as you probably wouldn't want your lead developer to be a Product Owner, because they'll tend to have a bias towards tech work, instead of customer needs.

I'm not a developer. I probably never will be a developer. But I understand the struggle. I know what it's like to be looking through the code trying to figure out why it's not working. I understand how frustrating it is to get distracted in the middle of this process. I know what different processes involved in software development are and I have a general understanding of them.

And that's what you need to do if you don't have the knowledge and experience yet.

Maybe because of people like me who have given the wrong impression that tech knowledge doesn't matter, many people are not even thinking about learning the tech side of things, which means their involvement in the teams is too superficial. Which may seem (or may also be) quite useless to the developers. And this extrapolates in the industry as "Scrum Masters don't understand devs so their involvement is only hindering progress, not helping it".

Your Agile assessment shouldn't only be about team dynamics

As I was writing, it got me thinking about how I interact with the dev team I'm working with right now.

As you might know, when I start working with a new team, the first thing I do is conduct interviews with everyone on the team and try to understand their processes and what kind of challenges they are facing.

In my initial interviews with the team I'm working with now, I asked lots of tech-related questions:

• What does your deployment cycle look like?
• What environments do you have?
• How much manual work is required to promote code to the next environment?
• What about manual versus automated testing?
• What's the state of your technical debt and how do you address it?
• Are you using feature branches or trunk-based development?
• Are you separating deployments from releases with practices like feature flags?

And many-many more because I need to help them improve processes across the board, not only improve how they run their meetings!

If you have no idea what I'm talking about in those questions, you gotta do some research and probably attend a couple of computer science courses to get up to speed.

Let's cover all the bases when we work with developers and bring as much value to them as we possibly can.

With that, I'm gonna leave you. Remember to go check the blog post and video on my website or listen to the full audio of the podcast episode.

​