Scrum Masters: Don’t Tell Development Teams How to Do Tech Work

My latest blog post for agile training provider Front Row Agile: “Scrum Masters: Don’t Tell Development Teams How to Do Tech Work.”

The Scrum Guide states that “no one (not even the Scrum Master) tells the development team how to turn product backlog into increments of potentially releasable functionality.” There is a good reason for this: The developers are the ones closest to the code, and are usually in a better position than the Scrum Master to understand what low-level decisions should be made and why. […]

This can be a challenge when the Scrum Master is in a hybrid role that requires being at least somewhat hands-on technically…

Read the whole thing on the Front Row Agile blog, and leave a comment.

Scrum Master Wanted: Competence Not Required?

A recent thread at Workplace Stack Exchange about managing developers who are more talented than you contains a comment that neatly sums up how to lead subject matter experts:

You don’t even need to be competent, as long as you listen to competent developers and don’t claim to know better.

I have written previously about being careful not to get stuck in your previous mentality as an individual technical contributor. Technical skill is often one of the factors considered when deciding whom to appoint as a team lead, and it is tempting to act like your leadership in scrum is still based on technical merit. But what happens when you’re assigned to lead people who are much, much better at something than you are (like at my current job)?

In scrum, this is a non-issue. The Scrum Guide clearly says,

No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality

Their skill level in relation to yours is completely irrelevant. A large part of your job is to foster a work environment where the development team can do their best work. You do this by listening to the developers’ needs and then working to remove any obstacle that keeps those needs from being met. Your ability to do that is not principally determined by your knowledge of object-oriented programming or web services.

Does that mean that a scrum master is not allowed to talk shop with the developers? Not at all. But if you’re going to talk with them in technical terms, and the developers really are in a different league than you in terms of skill, then you need to realize that almost any technical conversation you have with them will be for your own benefit more than theirs. One could argue that you are wasting their time by doing so. Be appreciative when they take a few minutes to explain something to you.

It is always helpful for a leader to have some understanding of the work done by those he leads. It increases your empathy with them, which helps you understand their challenges and what needs to be done to resolve them. But being good at what the developers do is not required (maybe it’s not even a significant plus) as a scrum master. I continue to be humbled in my job as I keep realizing how little my technical background actually matters. As we more deeply internalize the fact that our job is to help others do their job, any arrogance or intimidation we feel from comparing our technical skills with theirs will be replaced by the security that we are providing far more value to the organization by making their job easier than by trying to do it ourselves.

Don’t Let Your Technical Background Hurt You as a Scrum Master

It took me over a year after I became a scrum master to learn to stop making technical decisions. (I still do it sometimes.) This is a common pitfall for former individual contributors who are placed in a leadership position: they focus too much on what they used to do as individual contributors, and not enough on the big picture. It’s natural — that’s what you spent years doing and perfecting, and what you feel most comfortable with — but that doesn’t mean it’s right. Especially in a framework like scrum, where the team members’ roles are specifically designed to keep them from overstepping their bounds with one another.

One of the teams I worked with had a project that involved a lot of Python. Despite my having only a few months of experience in that programming language, it was still more than the rest of the team had and I was excited at being able to contribute my knowledge. I pushed for coding standards, participated in code reviews, discussed how the documentation should look, debated the use of third-party modules, encouraged the use of Git over SVN, and tried to understand in detail what the developers were working on. I felt proud of myself for providing some of the technical leadership on the project.

Then one day, an issue I had raised in a code review was rejected.  Had I been more familiar with the code, I wouldn’t have incorrectly pointed out what was really not an issue at all. Then it happened again. I found myself flip-flopping on dependency management because I didn’t fully understand the ecosystem the library would be used in. I started asking more “how” and “why” questions. There began to be some friction between the senior developer and me. My technical advice soon began reaching its limit, even though there was plenty of work left to do on the project. I started to get self-conscious and wondered if I was making a fool out of myself. (The team was nice enough not to say so directly, but I’m sure I did.)

My technical participation did have some benefits, but I insisted on continuing to do it even when it should have been clear that there were diminishing returns. I was not adequately fulfilling my role as a scrum master because, even though I was helping the team to create a high-value product, I was telling them how they should do it instead of letting them self-organize and decide on their own. And even worse, I did not have the necessary knowledge to continue providing useful guidance more than a few months into the project. A better way to help the team would have been to organize an overview of some practices I thought would be valuable and then let them decide if/how they wanted to adopt them, rather than practically dictating how they should do things. This would have allowed them to be more self-organizing, and possibly increased their sense of ownership and accountability for their work. I’m sure you can think of other ways that I could have handled those interactions better.

A lot of scrum masters come from a development background. They bring knowledge and experience that can help their teams produce high-value software. But as scrum masters, we need to remember that our role is not one of technical leadership, but of servant-leadership. Our mindset must shift from helping the team to helping them help themselves. Keeping this in mind and acting accordingly with our teams will help them do better work and foster a better working relationship with them, as we “respect each other to be capable, independent people.”