The ‘Scrum Master’ Job title needs to die
The product development industry is obviously in a very strange place these days.
Taken over by the ‘Agile’ movement, (a movement I consider myself a powerful advocate for) and yet still mostly failing to grasp the basic concepts of a manifesto written more than 20 years ago.
As Scrum has firmly placed itself as the single most popular framework to help teams and organizations on their journey to agility, the industry surrounding the teaching, certification and promotion of Scrum has taken a very central role in the overall conversation.
Now I must be clear, as a PSM-III holder, I deeply respect Scrum and it’s trainers and advocates who are tirelessly working to bend the mirror of traditional management, slowly moving us toward empowered teams and customer-centric value delivery.
But it’s impossible not to notice that the money that can be made selling certifications and training creates a powerful incentive to take pragmatism beyond the bounds of ‘supporting incremental change’ and perhaps crossing the line into ‘supporting bad practice so as not to risk losing sales’.
I believe this is no more strongly observable with the way the ‘Scrum Master’ job title has become the de facto standard way to manage (and I use that word deliberately) Scrum teams within an organization.
let me tell you why I think this has to change
Accountabilities, Not Roles.
Now to the credit of the Scrum community and it’s leaders, the Scrum guide was updated in 2020 and changed the scrum ‘roles’ of Scrum Master, Product Owner and Developers into Accountabilities.
This change was made to represent the fact that ‘job title’, or any existing organizational HR structure, has no relationship on the accountability a person is able to take on within a team.
This is a change that represents an important detail of Scrum; That it’s a framework built for self-managing teams.
The problem with ‘job titles’ is that they lock the structure of teams and organizations in place. If you hire someone as a Scrum Master, but the team doesn’t want to do Scrum, then you have a fundamental conflict with the nature of scrum, and its use by managers.
Thankfully, the change was made to the guide and it’s now easier to make the case that a Scrum Master is not someone inflicted upon the team, but someone who is part of the team, accountable for the teams effectiveness and Scrum Practice.
And yet, in the years since this change, there has been barely an inch of movement. Job boards are still full of “Scrum Master” positions, and most of the conversation in our industry seems transfixed on teaching Scrum Masters how to be Scrum Masters as if it’s the only thing they can or should do.
And this dovetails nicely with a second issue, that I believe also serves as our solution…
The problem with “Agile Coaches”
‘Agile coach’ is a role even less well defined or understood than Scrum Master, but I’ve seen the role become more an more common over the last ten years.
When done well, an Agile coach is a powerful advocate for change, who challenges the status quo in traditional organizations, supporting teams to improve their value delivery through targeted support and training, always connected to real, measurable outcomes.
When done badly?
Well, I’ve seen my fair share of ‘Agile Coaches’ who seem not to understand the basic concepts of agility, and who float around talking about ‘mindset’ and other nebulous theory, without ever being able to demonstrate real improvement or lasting change.
So if you don’t know me, you might read this article as a scathing critique of Scrum Masters and Agile coaches.
In reality, I consider myself both of these things. I’ve held both job titles, and others, over the last decade, and I actively switch between describing myself as a Scrum Master or Agile coach as the need arises. I’ve not been a hands-on practitioner, building products, for many years.
So no, I am not in any way hostile to people who perform these functions, who I believe to be absolutely vital to the success of our industry.
My problem is with the bifurcation of these two roles, and the way in which practitioners seem not to be able to unify on, and articulate, the purpose and value of these roles, or even the language we use to describe them.
So, returning to my original premise, I propose a solution;
‘Agile Coach’ is a job title, ‘Scrum Master’ is an accountability
In my view, ‘Scrum Master’ should be abolished as a job title, and it should be replaced with ‘Agile Coach’.
There’s that old joke
What’s the difference between an agile coach and a scrum master?
About two hundred dollars per day
Many people have talked over the years about the Agile Coach tag being redundant. A good Scrum Master does everything an Agile coach should do.
In most organizations, the existence of the Agile Coach role simply shows a misunderstanding of Scrum Masters, who’s accountability to the organization is often actively suppressed, leaving them little more than team admins.
And in other organizations, Agile Coaches are floating gurus who do little more than espouse short bursts of theory before moving on.
The answer, it seems clear to me, is that the HR, internal system ‘Job Title’ of ‘Scrum Master’ should be destroyed. Replaced with ‘Agile Coach’.
Then, an agile coach, when working with a team, may well take on the accountability of a Scrum Master.
This serves two purposes, giving organizations a way to tie agile coaches to teams in a more consistent way, to provide long term stable support, while also allowing ‘scrum masters’ not to be forced into a corner of enforcing Scrum upon unwilling teams, with no way to grow.
Seems confusing though..
I know a lot of people immediately think this just seems like pointless confusion, but consider that this is already how we’ve handled most other traditional roles in a Scrum Environment.
Most organizations still have ‘testers’ and ‘java engineers’, who, when part of a Scrum team, share the single accountability of ‘developer’.
Many organizations even still have the ‘Product Manager’ role, that within a Scrum team acts as the ‘Product owner’.
And perhaps you could argue that the change I’m suggesting is just a pointlessly semantic one.
But consider how many organizations fail to support Scrum teams to self manage. Fail to support SM’s to grow, and who end up introducing Agile Coaches as a pseudo-management layer to deal with the dysfunction this causes.
The answer, it seems to me, is simple.
Scrum Master as an accountability, Agile coach as a job title. Some Agile coaches will be tied to Scrum teams and fulfilling the accountability of the SM. Some will work with non scrum teams.
This empowers teams to find and solve their own team structural problems, without having a structure imposed on them by a HR department.
We practitioners have to argue this case more strongly
And finally, to address my initial concern, this is something I believe the vast majority of Scrum practitioners can see is an issue, and are not shouting loudly enough about it.
The change to the guide was made in 2020, and yet there is little to no conversation from trainers and experts to challenge the status quo.
Telling an organization that their entire HR structure and approach to Scrum is wrong feels risky. If we make ‘doing Scrum properly’ too hard, might people start looking elsewhere for support and training?
Might we lose out?
Maybe. I don’t really know. I just know we have to stick to our principles and challenge ‘the way it’s always been’, especially when we’ve already acknowledged the problem, but just aren’t making the case for real change that must inevitably follow.
Yes, change must be incremental. We cannot expect all job hiring to change overnight.
But I strongly believe that we should at least be making the argument, courageously and openly, that fixed ‘Scrum Master’ job titles undermine what Scrum is trying to achieve, and that, at least directionally, organizations should be trying to move toward a better way of organizing teams.