Making a Scrum Master redundant?

As published on LinkedIn Link

Every now and then, discussions come up as to how should one measure the efficiency of a Scrum Master? Is there a criteria based on which we can measure their performance? Does it depend on the number of impediments they help resolve? Is it related to the number of teams they are assigned to? Who or which department does a Scrum Master report too? And many more such questions. And then, an idea is usually floated that may be, a Scrum Master's ultimate goal is to make themselves redundant, a success criteria for a team. As pink as that idea sounds from a cost-saving perspective, it just doesn't ring a bell in my head. Probably, I'm not getting it, but here's my take on why a scrum master (even if possible) should not be made redundant (feel free to agree or disagree with my views in the comments below).

A man drawing on the white boardSource:

First of all, a Scrum Master is available if Scrum is in play. I have no clue who becomes redundant in a scenario where Scrum is not implemented. But let's consider the former situation and take a look at the responsibilities of a Scrum Master towards a Development Team as defined in the Scrum Guide:

  1. Coaching the Development Team in self-organization and cross-functionality;
  2. Helping the Development Team to create high-value products;
  3. Removing impediments to the Development Team’s progress;
  4. Facilitating Scrum events as requested or needed; and,
  5. Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.

Let's address these points one at a time.

Point 1, during the life-cycle of a product (may not be applicable to a project), development team members will change. This will invoke Tuckman's model as the Development Team goes through the stages of Forming-Storming-Norming-Performing. During these phases, cross-functionality and self-organisation may go through peaks and valleys. In the absence of a Scrum Master (who's also the Scrum Coach), achieving normalization will take longer which will hinder the Development Team's progress and ultimately become an impediment. So why get rid of the Scrum Master?

Points 2 & 3 always apply since the product is always improving and new impediments are always identified. In the absence of a Scrum Master, these impediments will have to be addressed by the Development Team members. If the resolution lies outside of the team's jurisdiction then the effort for enabling communication will hinder the progress of development which will ultimately become an impediment. So why get rid of the Scrum Master?

Point 4 seems unique since most of the recurring events can be setup initially, isn't it? But facilitation is beyond calendar invites (and a much larger topic to be discussed here). If the Scrum Master stops facilitating events then the Development Team members will have to do it; the preparation time for these events will hinder the progress of the development which will eventually become an impediment and require a Scrum Master's intervention. So why get rid of the Scrum Master?

And finally point 5, just like point 1, organisations grow and dissolve; it's Tuckman's model at a grand scale. Since most products may end up getting executed in a Scrum studio and external stakeholders may probably be unaware of Scrum, do we want the Development Team to be continuously disturbed by external environments? At the same time, don't we need a counselor so the Development Team members have a go to confidence person when needed? So why get rid of the Scrum Master?

In short, we can get rid of the Scrum Master, which will eventually become an impediment and will need a Scrum Master to intervene. Then why get rid of the Scrum Master?

Then what's the definition of success for a Scrum Master?

You will always have enablers in your team; a time may come when you may not need a dedicated full time Scrum Master based on your situation and your organisation's / team's setup. Although, I won't consider that as a success criteria else organisations will baseline their bonuses on how soon Scrum Masters exit a project.

I would rather create a Shu-Ha-Ri board for each of the responsibilities of a Scrum Master from the Scrum Guide and check where the Scrum Master fits with each of the responsibilities towards the Product Owner, Development Team, and the Organisation, just like an inspection.

An idealistic state would be that everything is in a Ri and the Scrum Master is not needed anymore; that'll probably never happen because of the points stated above. There will be times when the Scrum Masters are not needed and other times when they shall be called for. So the success criteria would be to move these fluctuations to a Ri state as soon as they drop to Shu or Ha.

Can this be compared between Scrum Teams or Scrum Masters? Of course not! But as long as a Scrum Master has most of their pieces in Ri (may be even Shu), I would term them successful. This would apply to any enabler / role in an organisation, doesn't matter whether Scrum is implemented or not.

What do you think?