There seems to be a big misunderstanding about the role of the Scrum Master going around in the Agile community. The phrasing people use differs a bit, but it always comes down to this:

“When you start a Scrum team, you need a Scrum Master, but after the team becomes ‘self-organising’, the Scrum Master role is no longer necessary, because ‘the team members can do it themselves.”

I have a number of arguments why this is simply not true.

Being a Scrum Master is an expertise

First and foremost: Being a (good) Scrum Master is an expertise. It is not just a matter of setting up the meetings and making sure people show up on time. (If you have no clue what else to do, have a look here or here. Or take my course. 😉 ) Becoming a good Scrum Master is a lot of work, takes years and as the profession evolves, you will need to stay up to date (your industry and the rest of the world also change by the way).

And because Scrum Mastering (it’s a verb right?) is an expertise, this means any Development Team member (developer, tester, whatever you have in your teams) would need to develop this expertise next to their skillset they need for the normal role (e.g. software development). Now I am sure there are people who can become and stay great in both, but I think honestly that is a very small minority.

Balance

Next to this: there is a specific reason why Scrum has three distinct roles. The roles and responsibilities are surprisingly well balanced. One of the reasons Scrum as a framework works well is because it recognises that a team functions better if it is facilitated well. Please do not misunderstand ‘facilitate’ to mean only ‘organise meetings and opening the conference number for the Daily Standup’. Let’s take Roger Schwarz’ definition from the Skilled Facilitator: “Group facilitation is a process in which a person (…) diagnoses and intervenes to help a group improve how it identifies and solves problems and makes decisions to increase the group’s effectiveness.” Having a designated person facilitate the team enables the team to focus more on delivery high quality work (and hopefully get into a flow). Taking out this separate role and placing the responsibility in the Development Team means that at least one person will need to be disrupted when something needs to be done (if it is a shared responsibility, it will mean everyone gets disrupted).

Change is constant

Finally, even if we ignore the first two points and assume we can take the Scrum Master out of the team when the team has reached this mythical state of being ‘self organising’ and not needing a Scrum Master anymore: companies change, team members come and go and products change or reach an ‘end of life’ state. Things change all the time. Even with well functioning, high performing teams, having someone responsible for team development and growth will help the team deal with the continuous stream of changes.

So what does change?

So does nothing change with respect to the Scrum Master role as it matures? Of course things change, although it is mainly the focus that changes. In the beginning, as a Scrum Master you will be mostly occupied with the mechanics of getting Scrum to work (in the beginning it can be hard enough to get things in a predictable and transparent way). You might be pretty hands-on, just helping get stuff done. In a later stage, as the team matures, you will probably not be so involved with every little user story that ends up in your sprint backlog. This gives you room to focus on things like team dynamics, solving structural impediments and helping your team’s environment become more Agile. Some people choose to take a second team at this point, which can work out, but it is often more challenging than you would think upfront.

Hopefully the arguments above convinced you. If so, I hope you will help me out with something: whenever talking about self-organising teams, let’s from now on stress that we mean self-organising Scrum teams (Scrum Master + Product Owner + Development team), not self-organising Development teams.

I will write some more about ‘what else can you do as a Scrum Master’ in a future blog post.

Thanks for reading.
Jasper