When Is A ScrumMaster Done?

Author: Alexey Krivitsky

Picture is taken from https://passion.digital/blog/2014/10/21/pr-seo-natural-digital-evolution/

• How many teams one ScrumMaster can handle?
• How can a ScrumMaster know if he's doing a good (bad) job?
• What should be next on your ScrumMaster's agenda?
• When is a ScrumMaster done?

Once you start working as a team coach (ScrumMaster) these kinds of questions are not uncommon. I keep asking them myself regularly. Because at times it feels like you're not making any progress. While your teams are coding, refactoring legacy, writing tests, automating deployment, shipping features... You're just scrum-mastering. It can really become hard to know if you're doing any good. I know how that feels.

One helpful way looking at this complex problem is by thinking of team maturity. Once I've realized that my work as a ScrumMaster has become more tangible, plannable, actionable and satisfying!

Most of you have heard the famous Tuckman model describing group dynamics: from forming to performing through storming and norming (there is the 5th phase 'adjourning', but we're not interested at it at the moment). The model has been out there for decades. It is powerful yet simple. And as all models - it is wrong but nevertheless can be useful at explaining complex phenomena like for instance team forming:

The model is so universal that one can explain pretty much any dynamics of human collaboration with it. For instance: you can explain by looking at it why young couples tend to fight; how companies perform after a merger; how teams react to process change. It can even explain how Scrum adoption within a team might look like.

I'll change the model just a bit to make it more visually appealing and slightly more self-explaining. That's how I learned to explain myself the Scrum adoption dynamics of a given team:

From my experience of bootstrapping Scrum teams (6 years of consulting in this field) I can tell you that the 'yellow' phase usually lasts 1-5 sprints. If it is taking longer the team is likely faking the Scrum rules (which sadly happens quite often and that's why an intolerant to scrum-buts coach is so useful at this stage).

If a team keeps practicing the core of Scrum correctly then after the happy 'yellow' phase (ignorance is bliss!) it will inevitably step into the 'red' zone. It is when the transparency (and Scrum is constantly reinforcing it) makes people see the things which they are not quite ready to see. 

- What's the best thing a ScrumMaster can do in the 'yellow' phase?

- Bring the team to the 'red' phase as soon as possible by helping them do Scrum correctly. 

- How does it work that by doing 'proper' Scrum a team reaches the 'red' phase?

- Scrum can be seen a super-set of feedback loops (product-, process-, team-wise) - every activity in Scrum contributes to one of the feedback cycles. Thus, by practicing Scrum teams enable incredible amount of feedback on how they are performing. The system starts seeing itself. That's why sometimes Scrum is compared to a mirror. The feedback the teams are now constantly receiving raise their awareness of the processes, impediments, environment. Facts are not harder to hide, issues are harder ignore... Hard discussions start to happen. That's the gates of the 'red' phase.

- How can a ScrumMaster help the team do Scrum properly at the 'yellow' stage?

- By simply being with the team: that can include pairing with a Product Owner, facilitating the Scrum meetings, helping everyone feel the heart-beating rhythm of sprints, celebrating often the small wins... Also making changes in the office space (simply by rearranging the desks) can make the feeling of the 'wind of change' stick.

- So why is that important to bring the team to 'red'?

- Because it is only after the 'red' phase the real changes in the organization can start happening. Though passing the 'red' phase can be really stormy...

Indeed, nothing prepared a team to know how lame its delivery process was, how badly the teams can make decisions, how poorly business people know the market, how inefficient developers are at maintaining clean code (well, this one they should have probably learned long before)...

Of course those things might make feel shameful. The faces would turn red. And if we could trust another powerful model of how people accept (or rather avoid) responsibility, then we could learn that: when we are ashamed, we are also very close to start justifying and laying blame on others. That is how you know your team is still in the 'red' phase. Because it is so easy to start blaming the process. "Scrum doesn't suite our culture... Scrum doesn't work... Let's make out sprints 6 weeks long... Let's try kanban*!"  

Have you heard some of the statements? If yes, then you exactly know what I mean by the 'red' phase. That's why I think this phase is most dangerous in the Scrum adoption. It is when a canary in the coal mine can easily die.

* Disclaimer: I don't have anything against the Kanban Method. Indeed, I respect and like its philosophy. I just don't appreciate when switching to kanban is used as an excuse for not solving organizational problems. In fact, once you properly start applying the Kanban Method, you'll likely face the same organizational dysfunctions that Scrum had mirrored you before. That's simply because they are attributed to your organization, and not to a given development method (unless a method is made to hide them, but that's another story).

- What are the things a ScrumMaster does during the 'red' phase?

- A good ScrumMaster empathises the team. He knows it is hard: he's been already there with other teams and helped them cross the chasm. Still he never stops encouraging to carry on. Proper facilitation of retrospectives becomes vital here as the team starts to surface uneasy problems. Focusing and helping see the positive by using tools like appreciative inquiry is the best what a ScrumMaster can offer.

- How does a ScrumMaster know the team is out of the 'red' zone?

- Well, that's usually obvious. Since a ScrumMaster is a skilled observer, one day he would notice team members discussing the next problem at hand. But this time instead of blaming other teams, managers, their Product Owner, the process - they are accepting the fact that the only way to change the situation is to start taking actions.

That's a huge change. I symbolize it on the model with a red vertical line that divides the model into two parts. It's an important watershed that once a team has crossed, it won't be pulled back again (unless you change the team by adding/removing people). It separates "doing agile" from "being agile". That's a cultural change. 

Once you're there everything feels easier and starts flowing. It might even start feeling boring - that's how relaxed the things are now compared to how they were just a sprint ago. It is usually the time a ScrumMaster stops seeing his benefit for the team.

- So what does a ScrumMaster do once a team reaches the 'blue' zone?

- Well, now he can just be resting on his laurels and write articles on how cool his Scrum is... No! Of course the job is not done here. Frankly speaking it is never done. But now a ScrumMaster has time to focus on a bigger picture: hiring, compensation, appraisals, style of leadership, communities of practice, continuous delivery... The world around is now seen and it needs coaching and better management.

- Does it mean a ScrumMaster can leave the team?

- Nope, not really. But he is no longer a central element everything depends on. If one day he goes to a dentist and is not showing up for a daily scrum, the meeting still happens as before - because the team understands deep values of the practices. Growing and mentoring facilitators within a team is very helpful at this stage. This frees up even more time for the ScrumMaster and also (what's more important) it helps the team own more of its process. Now a ScrumMaster can think of having the second team at a 'yellow' phase.

---

I've seen several teams at the 'green' level. And that's really inspiring and refreshing. That's one of the best things you as a team coach can observe in your carrier.

I've also sadly seen teams moving backwards on the model. The model is not linear. Agile is fragile. Any new team member with strong charisma and control-freak tendencies can bring the team down. That's why even 'green' teams need team coaches playing the role of facilitators and process challengers.

The world in fact is much more complex than any model... Still, I'm very interested to know if you find the model of Scrum Adoption Dynamics as helpful as I do.

Liked the topic and my style? The chances are you may also be interested in the following posts:

• A Monday in a Life of a ScrumMaster
  
• What ScrumMasters Really Do?