Shades of Scrum: The Scrum Master role

The Scrum Guide by Ken Schwaber and Jeff Sutherland states about the Scrum Master role:

„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 everyone change these interactions to maximize the value created by the Scrum Team.“

This definition states what the Scrum Master has to do but not how. And this is not a bug, it’s a feature. How to assume the Scrum Master role is highly dependent on the context. I like the situational leadership model to think about how the Scrum Master should do his job.

1. Telling: When a team hasn’t done Scrum before it is unable to do Scrum and insecure if Scrum would really work for them (bottom right cell of the diagram). In this situation the Scrum Master should tell the team members what to do. Providing lots of options to the team will often result in paralysis. The team just doesn’t have the experience to choose one of the options. In addition to the Scrum framework the Scrum Master may tell the team to estimate in story points and use Planning Poker for it.
2. Selling: After a short period of „Telling“ and delivering shippable product increments the team will move up to the top right cell. Now the team is secure that Scrum could work for them but is still unable of doing it (since it just did what the Scrum Master told them to do). Now the team is ready to take over a bit more responsibility and the Scrum Master moves to selling. He gives advice to the team and tries to convince them to do the right thing. In the „Selling“ state the Scrum Master explains in much more detail the whys of his advices. Now the Scrum Master may let the team decide if that want to estimate with story points or ideal days and wether they would use Planning Poker or something else. But the Scrum framework would not be modified by the team.
3. Participating: Now the Scrum Master leaves most of the decisions to the team (and just jumps in when there is something really critical). The consequence is that the team becomes more capable but insecure again. „Can we be successful with Scrum when we do it ourself without the Scrum Master managing the whole thing for us?“  The team starts to self-organize in the „Participating“ state. Now the team may decide to do the Sprint Planning in another way and may remove the Daily Scrum (but not the Sprint Planning, Review or Retrospective).
4. Delegating: Then the team experiences that it can succeed with Scrum without being dependent on the Scrum Master. Now the Scrum Master really acts as a coach leaving all decisions to the team. That means that the team may remove or adapt every single part of the Scrum framework.

In my experience switching between the left and right columns of the diagram is a challenge for most Scrum Masters. Some Scrum Master have the tendency to adhere strictly to the Scrum rules and give strict rules to the team. They are successful in the „Telling“ and sometimes in the „Selling“ state but often mess up the transition to the „Participating“ state. They just can’t let the team go.

And there are the Scrum Masters with a coaching mindset. They work successfully in the „Participating“ and „Delegating“ states but are challenged by unable teams. They often have problems providing the concrete guidelines to the team that it needs then.

One interesting question is of course: „Where is my team?“ A simple test is to not show up in a Daily Scrum. Will the team do a proper Daily Scrum? Then it is probably no longer in the „Telling“ state. What about the retrospectives? Is the team creative in finding solutions for its problems and does it implement the solutions successfully? Then the team is probably in the „Participating“ state. Or does the team just creates a list of things that other people should do? Or does the team create action items but fails in implementing them regularly? Then the team hasn’t reached the „Participating“ state yet.