Tanner Wortham is a ScrumMaster and coach who I’ve quoted on this blog before. He recently wrote a blog post entitled: When Can a ScrumMaster Say No which I read with interest.

I’ve been sharing of late around the notion of more prescriptive coaching stances and, at least in my mind, this seeps into the role of ScrumMaster. So I wanted to hear what Tanner had to say.

Here’s a snippet from the article:

[…] 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.

Two things struck me as I read Tanner’s article:

  1. It should be HARD to be prescriptive…to say no. In reading the article I could see that Tanner was “torn” by the need for prescriptiveness. I think that should be the norm. The minute we become comfortable with it, I think we’ve gone over the line.
  2. It’s totally situational. For every situation where saying no is the wrong response, I can think of one where it might be the better response over doing nothing. Another way of saying this is context matters.

Situational determinants

But before you run out and start telling every Scrum team you come in contact with “No” to everything, let’s examine some of the situational awareness you should have.

Overall results the team is producing

If a team is hitting on all cylinders, over-performing, and having fun doing it; then I’m incredibly unlikely to prescribe anything. I guess what I’m saying is that results matter (and speak for themselves).

And on the contrary, if a team is reluctant to listen or take suggestions, when their performance is lacking, then I’m much more likely to be prescriptive. And I’m more likely to “push them” towards the “basics” of agile. For example, adopting all aspects of core Scrum for a while and checking out the results.

Maturity of the team (cohesion, skill, experience)

Another consideration is team maturity across a spectrum of areas. For example, how long have they been operating as a team? Have the formed and moved to the performing stage? Does the team have the requisite skill balance to get their jobs done? Do they have the domain experience? And do they pair/swarm on their work collaboratively?

Of importance is their agile level of maturity. Are they a new team, just getting started? Or are they an experienced agile team who has hit the mark on hyper agile productivity and experience?

Quite often the Shu-Ha-Ri model is used as a reference in identifying team agile maturity and serving as a guide towards coaching engagement levels.

Point being, I would be more willing to tall a team no at the Shu-end of the spectrum and incredibly careful about doing it at the Ri-end.

Trending

I often say that a single data point, let’s say for instance velocity, isn’t really that meaningful in agile teams. It’s the trending that is the most interesting to a coach.

From a situational perspective, you can “trend” everything. Are the retrospectives getting better? Do you think team engagement is up? What about improvement in adhering to definition of done with respect to collaboration, pairing, and swarming?

I think you get more prescriptive if the trending is longer term negative. And in your coaching advice, I’d recommend using the historical data in the conversations. Often, teams are not as self-aware as you’d think, so this can be perceived as prescriptive, but also as simply shining a light on their declining performance.

Organizational Context

There is always a cultural and project context surrounding a team. For example, if there is a low-trust culture, then you’ll want to limit the amount of prescription you’re providing to really important situations. Otherwise, the team may lose faith in you.

Another example is if the organization is putting too much delivery pressure on the team. To the point, that they stop holding to their principles. For example, if the team began to “ignore” their Definition of Done and/or team agreements, I would surely put pressure on them to stop it.

And I want to redirect the “No” a bit from team ward to outward as well.

But beyond the situation, remember, it’s your job!

Over the years, I’ve seen so many ScrumMasters that never “say No” to their teams. Or say it to outside influences like stakeholders and managers. They somehow consider their job to be more enabling of the team and avoid any tough love situations.

But I think there is sufficient space in the Scrum Guide to warrant my recommendations and support Tanner’s view too.

Here’s a quote from the 2016 Scrum Guide, page #6 to support my thoughts:

The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.
The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps every one change these interactions to maximize the value created by the Scrum Team.

And from page #7 of the Guide:

Scrum Master - Service to the Organization
The Scrum Master serves the organization in several ways, including:
  • Leading and coaching the organization in its Scrum adoption;
  • Planning Scrum implementations within the organization;
  • Helping employees and stakeholders understand and enact Scrum and empirical product development;
  • Causing change that increases the productivity of the Scrum Team; and,
  • Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization.

In other words, saying “No”, is part of your job.

Stay agile my friends!

Bob.

1 Comment