The new Scrum Guide came out on November 18th 2020. This first major revision in three years softens the language of many ideas in the guide, making it less prescriptive and more inclusive of different kinds of work. It adds new ideas and changes definitions, such as the definition of a Scrum Master. In 2017, the guide said “The Scrum Master is a servant-leader for the Scrum Team” whereas now it reads “Scrum Masters are true leaders who serve the Scrum Team and the larger organization.“
The idea of the “servant leader” has been central to the identity of the Scrum Master role for a long time. Unfortunately, it’s one of the most misunderstood concepts in scrum. If we look at what the guide defines as the roles of a Scrum Master, we see these key words repeated:
- Helping – 5 times
- Causing, facilitating, ensuring, removing – 4 times
- Coaching, training – 3 times
- Leading – 1 time (in context of leading training)
This is not coincidental. In Scrum, the emphasis in the term “Servant Leader” has always been on the service part. (That’s why it’s the first word.) Unfortunately, many organizations that are not fully agile (and many managers in those organizations that may have little to no scrum training) see the Scrum Master as the agile equivalent of “Team Leader”, i.e. a manager.
Treating the Scrum Master as a manager is bad on several levels:
- It hinders the team’s ability to self-manage (or self-organize in the 2017 version).
- It hinders the organization’s ability to adopt scrum and empower the self-managed team to make its own decisions.
- It hinders the ability of the product owner to have the final say in the product by making the team a two-headed monster where two people control what team does
- Most importantly: It hinders the ability of the Scrum Master to execute their job effectively.
Making the Scrum Master a manager is bad. Trust me, I’ve been there. I’ve been a Scrum Master/Team Leader, and it is almost impossible to wear both hats at the same time.
By making the Scrum Master a manager, the organization makes them accountable to management first, and their success is measured by how successful is the team in executing the management’s decisions. It also makes the Scrum Master the management’s representative within the team (and it kneecaps the Product Owner in the process, since it is the POs job to represent shareholders’ interests through the backlog). It breaks trust within the team, it can hinder openness (team members are less likely to offer honest feedback when management is present), and it can lead to less transparency. It makes the job of the Scrum Master harder since suggestions made through “coaching” and “mentoring” become essentially managerial directives. And so on.
So what’s the solution? If we could trust everyone who uses Scrum to use it correctly, that would be ideal. Failing that, I feel we should stop calling Scrum Masters “Leaders,” because it’s confusing. Personally, as a facilitator as well as SM, I prefer the term “Scrum Facilitators,” but to many a facilitator is someone who is outside the group, whereas a Scrum Master clearly has skin in the game.
If that thought sounds too cumbersome, how about “Process Owners”? It would make a nice counterbalance to the definition of a Product Owner, and defines the idea behind the Scrum Master without having to use the “term leader.” Jeff Sutherland, Ken Schwaber, can we put this on the backlog for the 2023 revision?
