Scrum Masters don’t own the process.

Despite what many job descriptions say these days, as scrum masters or agile coaches, we are not enforcers. We do not own or overtly control the process that our teams use. We are coaches.

A revision of the scrum guide in fact now even better reflects this. It went from:

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.

To

The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.

In my opinion, coaching is one of the hardest but most essential parts of our jobs. Not only do we need to know enough about agile theory and practice so that we can provide training and mentoring, we also need to be comfortable and prepared to help teams change in the way they wish and arrive at decisions and solutions that are theirs.

Shuhari

Sometimes in interviews I ask candidates how they would introduce scrum to a team. The answer is usually “Shuhari”, a three step concept for learning techniques. However this doesn’t answer the question of how the team starts with with this concept.

While I generally agree with the “don’t knock it ’til you try it” rationale behind this, when it comes to the first stage of Shu, teams are often not given a choice. As a result I feel this concept is (ab)used as a way to force teams to do scrum the right way and to control their process development. This comes dangerously close to:

1. Believing that following a process will somehow make you agile and;
2. Violating the first value of the agile manifesto:

Individuals and interactions over processes and tools

If we really want teams to be more agile, that is one that inspects and adapts in order to continuously improving itself, then they need to be able to question, challenge and think for themselves. We don’t want them to follow a process or practice just because we told them to. We want them to do it because it was their decision. Because we interacted with them, coached them, built a relationship with them and gave them knowledge and context to make their own choice. Because we encouraged them to take responsibility for their ways of working and not always rely on and look to us for answers.

In my experience, people tend to react more positively when you take the time to explain the reasoning and principles behind an action requested of them, but also when you place trust and respect in them i.e. treat them like adults. In return they will also put their trust and respect in you.

Even if the team willingly enters into Shu and agrees to just follow the process, it is still up to the team. They follow the process only as much as they decide to and can back out at any moment. If this decision is premature, perhaps you may need to double down on your coaching 🙂.

The other thing to remember is that shuhari comes from (some) martial arts, and while the concept can still be somewhat transferable, scrum is ultimately not a martial art.

• In martial arts, Shu would normally practiced in a controlled and safe environment. This is almost always not the case when introducing scrum (or any other agile framework).
• Unlike a martial art where occasionally you might find yourself in need of delivering results/ defending yourself, if your team is following scrum then it is likely that they are already in an environment that expects them to deliver frequently.

The very nature of Shu runs counter to the first agile value by purposefully valuing process and practices. When employed simultaneously in a complex, real-time environment where people often erroneously expect that the simple application of these practices will bring immediate results, the risk of cargo cult behavior is high. As a result not only do expectations need be managed, but Shu as a learning stage is generally short-lived out of necessity.

Shuhari as a maturity model

Shuhari is sometimes transformed from an abstract learning concept to a tangible maturity model for ‘assessing’ the agile level of teams. The problem with this is that maturity models are linear and grossly oversimplify the nature of a team or individual’s complex development— which begs the question: If they generalize so much — what exactly is it’s worth?

When you think a team is at Ha, they will inevitably be at Shu in some things and maybe even Ri in others. And then this might all change the very next day when they are blamed for being too slow by a command&control management team (which arguably is the more pressing problem that you haven’t yet addressed because you were too busy trying to determine whether your team is at Ha.)

On top of this, who decides the criteria and when a team gets to move to which stage? Should it apply to all teams, no matter their size, work-type, composition, constraints etc.? Will it create some kind of rivalry or comparison between teams? And why should we care what level they are?

The most important thing is whether the team is continuously delivering value or not. If they aren’t, the team needs to have a conversation, retrospect and adapt accordingly. Whether they meet some arbitrary criteria and are given a stamp of approval by their scrum master is irrelevant and simply bike-shedding. Such maturity models end up representing control mechanisms for scrum masters (or management) who want to have authority over the team’s process because they believe they know what’s best — incidentally a trait of largely out-dated scientific management and an anti-pattern of leadership in volatile, uncertain, complex and ambiguous environments.

Summary

This post may sound a lot like I am encouraging anarchy, but it couldn’t be further from the truth. Without this control over the process, some scrum masters I imagine might also feel lost. What is my role then? Your role is to coach — to help teams and individuals find their own way, but still provide them with the support and knowledge of tangible best practices. This also means understanding not just the benefits of concepts like Shuhari but also their limits. This is a lot harder than just enforcing, but it’s also a lot more rewarding.