What do developers want from Scrum Masters?

Developers hate Scrum Masters. That’s an overgeneralization, of course. But we can see some keyboard warriors in the comments section.

*sigh* … and *facepalm*

So in this video, I wanted to share some thoughts on what I believe developers actually want (and don’t want) from their Scrum Masters.

This is just my personal opinion, but it did help me build a strong foundation for good relationships with the developers in the teams I worked with.

There were some exceptions. But I believe that I did a good job overall.

I’m sharing a snippet from a mentorship call where I discuss this topic and share some practical tips on how to build rapport and get some quick wins as a Scrum Master.

From the developer’s perspective, what might they be interested in asking me as a Scrum Master?

What do they want? They want an easier life.

But maybe let’s think about what they don’t want.

They don’t want to have constantly changing priorities, which often happens.

They don’t want to have stakeholders always be disappointed in them that they’re not delivering while the problem might be not that they are not doing the job, it’s just that there are dependencies.

They will definitely want to have a more sustainable workplace generally especially if there are a lot of demands coming their way.

Often people just feel overwhelmed because there is the Product Owner roadmap, and then the customer success team, for example, is sending them bugs all the time.

Very possible if there is technical debt in the product, most likely the team often doesn’t have time to actually get to it. The team has all of these items they need to fix that are not technically on the roadmap. They need to be fixed because it is making the developer’s lives much harder.

And then everybody says “Well, once we finish our roadmap items, we will work on the technical debt“.

And then, They carry over the roadmap items, so they never have the time to actually work on what really matters to them. And that can be also frustrating, obviously.

In this case, when a new Scrum Master comes in, the developers might be worried about you coming in and taking more of a stance from the Product Owner’s point of view, a stakeholders’ point of view.

And that will just add one more person trying to push through more new features and not think about the tech debt since you are not technical, so probably you don’t understand it.

I think it’s important if there is a chance to talk about that, to say that it’s important to always plan for the technical debt and for fixing bugs when we are planning for the sprint.

“We’re taking this into account that I, for example, personally believe that you do need to set aside some time every single sprint on technical debt“, and developers see that you are one their side too.

Because it means that you understand the challenges that they most likely are, facing.

So talking about that, that, you know, when we’re working on roadmaps when we’re working with the product people that we think about that technical debt part as well, and we plan for it properly.

It’s possible that they have been working in Agile for a really long time. They still might have reservations about some things.

Maybe they didn’t have a really great scrum master previously, or they don’t really know how you would approach the work and they might be afraid that you will come and start changing things.

Like a storm: we’re going to change this process, throw away your Kanban, and recreate something new.

When I start working with a team, the first thing I do is try to figure out how the team is working, what the processes are.

There are always some decisions made around the processes for a reason, so I’ll want to understand why they are doing things a certain way before I can really start making any changes.

And the goal is not to just change for the sake of change. Your goal is to find quick wins. Your goal is to find out how can you help, resolve some of the pain points the team is facing.

That’s kind of that what developers in an Agile team really want. They want you on their side basically.

I think what you’ll want to show for with the developer especially just appreciation for their work. Because they don’t really understand what you do for them. You are just doing something that has no tangible results. They are working on something very, very tangible.

And you are not technical, so what value do you bring?

I think always important to say:

“Hey, you are an expert in this technical stuff. I have no idea how to do that. And I think that it is really amazing what you can do. I know that developers are passionate about what they do. I know that you want to deliver great products and you care about the quality of what you build.”

Just showing appreciation for that work because often there is animosity between the business side and the development side because they don’t really understand the complexity of the work of each other.

What to focus on when starting with a new team

It’s important to not force new changes on the team you start working with.

That is why I usually spend the first couple of weeks trying to understand the context of the team and the organization: why certain decisions were made? why certain processes are in place? what’s the history of this team?

This is the most useful way to spend your time at the beginning.

I’m sharing more practical tips in my video on what to focus on when joining a new team.