Does A Scrum Master Need To Understand Software Development?

I’m encountering more and more Scrum Masters who work with software development teams but don’t have a background in software themselves. Is that a problem?

Hi there. Today, I’ll attempt to answer the question:

“Does a Scrum Master need to understand software development?”

As the question is phrased, my answer is: No.

But first, it doesn’t hurt if he or she understands something about it. And second, it depends on what you count as “software development.” I’ll explain with an example.

For a team to collaborate successfully, internal communication is essential. So, a Scrum Master is doing a good job if they pay attention to communication and work on it with the team when needed. I assume this is broadly stated enough that every reader will agree.

It gets interesting when you ask:

Where does communication happen in a software team?

The obvious answers include meetings like the Daily Scrum, Review, Retrospective, Refinement, and so on.

But what about Pull Requests?

Pull Requests are an important part of team communication. I’ve worked with teams that were calm and tame in meetings, but tore each other apart in Pull Requests—total battles. The “good” programmers versus the “bad” programmers. Blaming and finger-pointing straight from the textbook. Nothing that was even a hair less than “perfect” was accepted. (Perfectionism is one of the many surprising roads to hell, but that’s a discussion for another blog post.) Some pull requests dragged on for weeks.

The result?

Team members silenced to the point they couldn’t make a move on their own. Their focus shifted to self-protection, no longer on productive work. Commitments in planning? Rarely happened anymore.

What does this have to do with the Scrum Master?

If the Scrum Master believes they should avoid the software’s source code like the devil avoids holy water, then they’ll miss this whole part of team communication. Because putting someone down in the more “protected” space of a pull request—writing instead of speaking, asynchronous instead of synchronous, not face to face—is easier than doing it in team meetings, this kind of toxic behavior can smolder for a long time. By the time the flames break out, it’s (too) late and the house is proverbially on fire—and the Scrum Master is left wondering why.

When I work with a software team, I sometimes look at a few pull requests too. Recently, I tried to do this with a client and was surprised to find I didn’t have access. There were only a limited number of licenses for the system being used, and no license had been purchased for the Scrum Master. Short-sighted.

What can I do as a developer?

One simple solution: Invite the Scrum Master to (some) pull requests. If you’re in a company that avoids license costs, advocate for spending the money.

Another approach: Review pull requests together with the Scrum Master, like in pair programming.

Until next time…


This article was originally published on heise.de in the german version.