When Can a Scrum Master Say No

When can a Scrum Master say no to the team?  That’s a question I struggled with as a young Scrum Master.  On one hand, I was told that I have only influence—not authority—over the team, but on the other, I was told that I was the keeper of the process.  So what do I do when the team tells me the retrospective is a waste of time and suggests doing away with it?  If I could turn back to the clock, here’s what I’d tell my younger self.

When listening to a team, I ask myself a two questions:

• Does an idea conflict with the intent of a ceremony? As Scrum Masters, we should not only understand the mechanisms of a ceremony.  We should also understand their intents, which I write about here.  When we understand the intent of each ceremony, we empower the team to tweak the mechanics to suit their needs.
• Is the team trying to toss out an element of the scrum framework?  Examples of this include delaying testing until the next sprint, not delivering working software at the end of the sprint, or doing away with a ceremony altogether.  Use this video as a reminder of the simplicity of the scrum framework.

If we answer yes to either question above, what we’re likely hearing is a symptom of a bigger problem.  I suggest approaching it in the same manner your doctor might.  If you tell your doctor about your terrible cough, he or she won’t tell you that he won’t treat it.  Instead, he or she will ask probing questions to better understanding the problem because he wants to treat your illness, not your symptoms.  It’s the pneumonia he wants to cure.  The cough is just what brought you to him.

Let’s say our team wants to do away with the sprint review.  Ask them why they aren’t deriving any value from the ceremony.  Are the stakeholders asking about work they did three sprints ago at the review?  Are stakeholders too talkative?  Too quiet?   Is there little to show at the sprint review after our two week sprints?  What can we do differently that will solicit helpful feedback? Knowing we’re headed in the right direction is helpful, right?  This is our chance to learn this.  Finally, remind them of something they may have forgotten:

Scrum is not a problem solving framework.  It’s a problem finding one.

Doing away with the sprint review simply ignores the problem.  Help the team experiment with new ways to conduct the review but that align with the intent.  Over time, they will find their solution.  At no point did we have to say no.  In fact, we should avoid it.  I believe our responsibility is to understand and to guide.  Rarely is it to deny.

Even so, I occasionally encountered two situations where I’ll say no as a Scrum Master:

• Moving the sprint review. Our team knows going in when our sprint ends.  Another few hours or another day isn’t going to yield as much progress as they hope.  As I’ve said before, the last 10% of any story is chock-full of dodo birds and unicorns.
• Working with new Scrum teams. Before we begin, I set an expectation with new teams that I intend to be rigid with our implementation of the framework, which sometimes compels me to say no.  The intent is not to be difficult but to teach the ceremonies as they’re intended so we can expose and resolve team and organizational issues.

That’s all for now.  I welcome your feedback in the comments below.