Taking Initiative over dedicated Scrum Masters

The second value of the Post-Scrum Manifesto states "Taking Initiative over dedicated Scrum Masters".

To understand what this means, we must briefly glance at why we even have Scrum Masters in Scrum.

 

The role of the Scrum Master

Who is the Scrum Master anyways and what do they do? A small (yet in Scrum trainings, most emphasized) portion of their responsibility is keeping the rigour of Scrum, reminding stakeholders and team members of their role, facilitating the events and getting impediments solved.

Probably the biggest responsibility is moulding the developers into a team, creating a powerful workforce able to cooperatively turn user stories into valuable, working software - by any means necessary.

And with that, the Scrum Master's main responsibility is: to become superfluous.

What happens when you don't have a Scrum Master

For example, teams who are not aware of the Tuckman model may never reach a superior performance: Being busy fighting fires day-in, day-out may prevent progression. A Scrum Master should be aware of this situation and free the team to pass through the Storm.

Initial teams often abandon "pure Scrum" very quickly: Daily Standups turn into detail discussions or get skipped altogether, Review Meetings become Tech Talks, Retrospectives become venting sessions. The Scrum Master guides teams to be more effective, but also coaches members on why these events are important and what their intended outcome is - and when they are missing the mark.

For many organizations transitioning to Scrum this statement is (should be) applicable: The Scrum Master is empowered to resolve impediments outside the team's sphere of control. They may freely move beyond team boundaries to make the team more effective. Most of all, not being a developer, they have time to do this.

And, let's not forget the most important aspect of becoming agile: It does not suffice - or, to put it more bluntly: It does not work - to have "a bunch of nerds in IT doing Scrum". It may help a bit when things are in utter chaos. To be effective, the organization must embrace agility. The Scrum Master should evangelize management, stakeholders on the benefits and responsibilities of working in an agile context and win other developers who are currently working in less effective structures for the new, improved approach.

Why having a Scrum Master on the team is bad

Let us start with the most important responsibility of the Scrum Master:

Orchestrated Agile transformation

Disclaimer: There is nothing, absolutely nothing wrong with bringing experience on board.  When everybody looks to one person "So, how should we do Scrum?" - that's a terminal disease: Failure and success of Scrum would hinge on one person. However, Scrum is a team discipline, so that's counterproductive. Deming realized a good 30 years ago in his 14 Principles that "the transformation is everybody's job!".  As such, everybody should be leading the Agile transformation.

Lack of impediment resolution

It is good if there is someone on the team who can assist developers in removing their impediments. However, there is already an organizational issue when people are impedited and unable to resolve this by themselves. Having a mindset of "I can not resolve this by myself" is a killer to motivation and productivity. As such, every team member should feel both responsible and empowered to remove their own impediments.

Ineffective Events

Events, such as the standup are not for Scrum. Much less are they for the Scrum Master. As long as team members rely on the Scrum Master to facilitate events - at worst: reporting to the SM -  they do not reap the full benefit. Each event serves a team purpose, so it should not even be necessary for the SM to organize or attend these: The team should drive every events that is valuable to them! 

For this, every team member should understand the value they obtain from a event - the SM can't do that for them!

Fixing symptoms, not causes

Each time the SM intervenes against outside interference to keep the team uninterrupted, that is a fix to the symptom. The root cause is that someone doesn't understand what they are doing. It is good to have a pitbull biting anyone who unknowingly damages productivity. It is better if there is nobody who does that.

Wrong source of improvement

The team members may justified have trust in the SM's ability to improve, but every activity introduced by the SM does not originate from the team, which means that they did not have the mindset to identify the problem or come up with the solution. The very fact that the SM adds value to the team is a shortcoming of the team. In a truly self-sufficient team, an SM can not add value.

Driven evangelization

It is good when the SM can evangelize others in the agile agenda. It would be better if the team's results would inspire others to participate. As the old adage goes "Preach by any means necessary. If inevitable, use words." - the SM can assist as an information radiator, ideally the team is already a shining beacon. The SM can (should) not be busy establishing disciplines like software craftsmanship, refining backlogs etc. in stead of the team. The more they involve in these activities, the less mature the team is.

Summary

Anything that the SM does for the team indicates a dysfunction in the team. There is no excuse for anyone on the team to not be doing what the SM does. A good SM is the key ingredient of a highly successful team. A great SM will make themselves superfluous.