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.

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 read about them in the comments section.

Part of a Scrum Master’s Job is to Lose It

Two weeks ago, a developer on our team told me that he wanted to have a sprint planning to go over a code change that he and another developer had been discussing (most of our work is done through Kanban these days).

A sprint planning session would have been overkill for what he was proposing and the number of people involved, but I was very pleased to hear him make the suggestion nonetheless. Last week, I proudly congratulated that same developer when he told me he had passed the Professional Scrum Master (PSM) certification exam. At this rate, he will hardly need me in a couple of years (if he even does right now).

The Scrum Guide states that one of the Scrum Master’s responsibilities is to “[coach] the development team in self-organization and cross-functionality.” Implicit in this statement is the notion that a Scrum Master should work him or herself out of a job.

A coach helps people understand and do what they still can’t understand or do themselves, with the expectation that they will eventually be able to. This is what nutrition coaches, fitness coaches and business coaches do. Therefore, a Scrum Master who serves as a coach should help the development team grow to reduce their dependence on the Scrum Master.

This is not exactly the same as helping individual contributors move into management. Some people want to become leads, managers or executives, and that’s fine. Some don’t, and that’s also fine. You should not force someone into a job role that they do not want.

But since a Scrum Master is not a traditional manager (though the name of the role continues to inspire that misconception), but rather a facilitator, you should expect a development team to continue to grow their skills that help them communicate and work with customers, business stakeholders and other development teams. That should be part of their natural career progression.

Of the three roles in a Scrum team, arguably the one you could most easily do without is the Scrum Master (although you would technically no longer be following Scrum). This does not diminish the Scrum Master’s importance, nor does it mean that the Scrum Master’s role ever really goes away, as Mike Cohn points out in this article.

It is, however, a reflection of the fact that the product owner and the developers must have hard technical skills in order to get their work done, whereas a Scrum Master is essentially a collection of coordination skills concentrated in a single person. You do not expect an experienced product owner to eventually develop coding skills, nor do you usually expect a developer to decide which backlog items are the most important to a company.

But you do expect both of them to become progressively better communicators, planners and collaborators. And that’s really all a Scrum Master does within the scaffolding of the Scrum framework: Foster better communication, planning and collaboration between the business and the developers.

Remember that your goal as a Scrum Master is not to still be chasing resources in five years the same way you do today, but rather to have guided the team to a point where you are their point of escalation instead of their first resort whenever they hit a snag. Coach the team on the importance of planning so that a sprint planning session is no longer just an hours-long ordeal to be endured, but something so natural and necessary to getting quality work done that they bring it up themselves.

By helping the team understand and do what you understand and do, you create a virtuous cycle that helps your current team members, future team members and other teams that your developers will eventually be part of.

Do you agree with my assessment of the Scrum Master’s role? Let me know in the comments section below.

Don’t Skip Your Recommended Daily Dose of Scrum

Can you remember what you ate a few days ago? How about a week or a month ago? We only tend to remember the extraordinarily delicious (or extraordinarily un-delicious) meals.

But all of them were important, even if we don’t remember them. How do we know that? Because if we hadn’t eaten any of them, we would not be alive right now. Similarly, missing a meal every now and then won’t do you terrible harm, but if you do it frequently enough, you will start to lose weight and become weaker.

In this way, daily scrums are like food: they play a vital role in keeping your team’s development process healthy. But, for some people, the daily scrum is an acquired taste. Sometimes it can feel burdensome, unnecessary or un-delicious, and you would rather skip it altogether. Resist the temptation.

Here are some objections you might hear from developers, product owners or even management regarding the daily Scrum. Perhaps you have even felt this way yourself.

“It’s boring. The code they are working on has nothing to do with me.”

The daily Scrum is a way to keep everyone informed about what everyone else is working on. This is important for cultivating a cross-functional team. Team members also learn how the code they are working on fits in with other code that someone else is working on, which is especially important if not everyone in the team is working on the same project.

And, even if they are working on entirely different applications, the types of issues different team members face can have common traits. If Alice hears that Bob, a junior team member, is wrestling with a memory leak that she knows how to fix, she can take that opportunity to coach Bob.

“Developers already talk to one another throughout the day. We don’t need a daily meeting for that.”

The spontaneous conversations that take place during the day tend to be operational in nature: Alice has a compiler error; Bob needs some information from Carol before he can define an interface; Dave can’t figure out why a file is missing and so on. They are focused on fixing immediate problems, whereas the daily Scrum is more of a tactical planning meeting.

It is not a problem-solving meeting, but rather a problem-surfacing meeting. You find out who is blocked and who can help, or who can find out who can help.

“This is a status meeting.”

Yes, developers share their status. But that’s like complaining that you must inhale in order to breathe. If the daily scrum consists solely of answering the three questions of what did I do/what will I do/what is holding me back and nothing else, then it is indeed just a status meeting.

But, just like you can’t breathe by only inhaling and never exhaling, your daily Scrum will not be effective if all of the communication is pointing away from the developer and there is none in return. As mentioned above, the daily Scrum is a problem-surfacing meeting, and problems can go unnoticed if no one comments or asks any follow-up questions. The Scrum Master might need to take the lead in digging a little deeper while the rest of the team develops the confidence or interest to do so themselves.

“It is ineffective or rude if you don’t let anyone except developers participate.”

Would you need people from outside the team to participate in a technical coding discussion? Would they even want to? The daily Scrum is a higher-level meeting than that, but only by a hair. If people can see it that way, they might be less inclined to insist on participating. And, with a 15-minute timebox, there isn’t much time for other people to participate effectively anyway.

Having daily Scrums is like maintaining a healthy eating regimen. You might not always want to do it, and some of the meals might be bland or occasionally downright yucky, but you can’t skip them. You might not see an immediate negative impact from doing so, and people might even be happy about it (yum, junk food!).

However, it can erode your team’s agility and cohesiveness over time. Similarly, positive effects may take time to manifest, but they will help your team bond and achieve an elevated level of performance.

Have you heard any other objections to the daily Scrum, from team members or otherwise? I'd love to read your experiences in the comments below.