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

I recently found a type of paper slip in my post office box that I had not seen before. Thinking it was for a package delivery, I handed it to the lady at the counter, who grimaced. She and another employee explained with some frustration that it was used as a second-notice slip, but that sometimes the system printed them out even after the package had been handed over (the other employee did, in fact, return empty-handed after looking for whatever package I was supposed to receive). What surprised me the most was their assertion that this process must have been thought up by someone who didn't do the actual work of customer service.

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" (emphasis added). 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.

A Scrum Master might come from a technical background in the same area that the team is working in, and might in fact be more experienced than the developers, but that does not give them the right to guide the development work. The Scrum Master's job is to guide the Scrum process, not the implementation of features. This can be a challenge when the Scrum Master is in a hybrid role that requires being at least somewhat hands-on technically. Scrum Masters who are asked to serve as team leads must find a balance between letting the team be self-organizing and actively taking part in producing quality code.

Your best allies in that situation are technical leads or other senior developers who can give "teeth" to any rules you propose, as well as let you know which of the rules that you're proposing make no sense. Getting them on your side will improve your technical credibility with the rest of the development team, whereas trying to enforce technical guidelines if you're not involved in doing the actual work can earn you the development team's disrespect and even disdain.

For example, I stopped being a full-time developer a couple of years ago when I moved into my current project manager/Scrum Master role. During that time, we received a ticket in the form of an unhelpful generic error message, and I somewhat forcefully told the developer at the time that we should not be using generic error messages. But it wasn't until I started getting back into code that I realized just how out-of-touch I must have sounded. Ideally, yes, all your error messages should be clear, helpful and actionable. Realistically, however, the sheer number of possible failure points sometimes makes this impractical.

Forcing developers to work at the level of detail that you think they should can easily turn into a distraction from the more important tasks they should be doing. Just like whoever came up with the idea for that post office paper slip probably had good intentions, but might not have understood how it would impact the employees' work.

There is a caveat to this. The Scrum Guide also says that the Scrum Master is allowed to participate in "executing the work of the sprint backlog." Doesn't that mean they are allowed to lead technically as well? My interpretation of that is that the Scrum Master can lead technically as a developer, and that their leadership role is limited to their technical merits, just like it would be for any other developer on the team. Their technical leadership does not come from the fact that they are wearing the Scrum Master hat. If they are working in a project manager-type role and just feel like calling the team out for doing X or Y because they think they know the best way to do it, then they should channel their concerns through other developers instead of trying to get the team to accept their technical edicts directly.

As a Scrum Master, even one in a hybrid lead role, try not to dictate how software should be built. Do communicate the "who, what, when, where and why" so the team doesn't feel like they are developing in a vacuum. But leave the "how" to the subject matter experts, which, in this context, usually does not include you. This will help you build a strong, mutually respectful relationship with the development team, and allow all of you to do your best work without encroaching on one another's responsibilities.

---------------------------------

This article was originally posted on the Front Row Agile blog. Have you had any positive or negative experiences in trying to be a technical coach while also being a Scrum Master at the same time? I'd love to hear your point of view. Drop by the Front Row Agile blog and leave a comment.