A practice very common in organizations is to hire Scrum Masters as an official HR title. Complete with a list of expectations and measures gauging their success. Read on to learn why I believe having Scrum Master as a title is a mistake, an anti-pattern that will likely lead to lower team effectiveness.
Questionable Expectations
Scan through some online job adds for Scrum masters and you’ll like see quite a number of questionable expectations from companies. Ask other agilists and review your environment to find even more.
Some of the most prevalent include:
- Scrum Masters facilitate all team events. Initially this can be true for teams entirely new to Scrum. Those teams are becoming fewer and further between. Many teams and team members have prior Scrum experience.
- Scrum Masters remove team impediments. I have yet to meet a Scrum Master who is also empowered to remove these impediments.
- Scrum Masters are highly experienced in specific ALM tools, most often Jira. This expectation commonly results in the SM becoming the team admin, updating Jira before standups, during Sprint Planning and Review. Teams should be taught they are collectively responsible for tool updates.
- Prescribed metrics, workflows and dashboards. Scrum Master are often discouraged or even blocked from helping teams inspect and adapt their workflow to context. They are expected to use a one-size-fits-all approach. While not entirely related to SM as a title, people will be far less likely to challenge such a requirement. Challenges to these expectations could be job limiting or ending.
While some of these expectations may be advisable initially, they form the basis of how Scrum Masters are reviewed for performance evaluations. Challenges to the status quo is discouraged as it could lead to a negative performance review, or worse. I have seen a number of Scrum Masters put on performance improvement plans for actually helping teams evolve beyond Scrum by the book.
And that leads us to…
Questionable Measures
Scrum Master performance evaluations will almost certainly attempt to measure how close the Scrum Master adheres to the Scrum Guide. Or perhaps even worse, the organization’s redefinition of Scrum.
Facilitating all team events is perhaps top of the list for measuring Scrum Master performance.
Even though not part of Scrum, it is likely that Scrum Masters be required to measure, track and plan using something like Story Points and velocity. These type measures are of no value beyond a team. Lean metrics provide far better information for managing flow and generating forecasts.
Framework Lock-in
This is my largest concern with Scrum Master as an official HR title. If it’s coupled with the anti-pattern that the Scrum Master reports to the same manager as the team it can become magnified.
When someone is hired with the title of Scrum Master, and their performance reviews measure them as a Scrum Master, how likely will they be to evolve their team(s) away from Scrum?
Scrum Masters are told, in Scrum Master training, that one of their primary jobs is to “work themselves out of a job”. Sounds great as a theory, right? But will that hold up when it could literally be their job on the line?
Will they teach teams to own their ways of working or will they keep the team dependent upon them to manage Jira, facilitate all the events, do all the things the Scrum Guide and HR says they should do?
In other words, will they “lock” teams into using Scrum?
Working themselves out of a job with a team, when their official title is Scrum Master, may require them to do an HR transfer to find a new team to help. This is the main difficulty when the Scrum Master reports to the same manager as the team. Unless the Scrum Master group is centralized, there is no incentive to “work yourself out of a job” because that almost certainly requires you to transfer to another group. Such moves are often hindered by requiring “slots” to be moved or other budgeting negotiations.
Beyond the above, there are many teams whose work is not iterative in nature. They do not incrementally create value. They are more ticket based, or at least work that is not informed by feedback. But because the Scrum Master would not be necessary, they do not adopt a continuous flow model. More here: If You’re Not Doing Iterative Work, Why Are You Still Using Scrum?
Alternatives
I honestly believe Scrum can be an effective way to introduce teams to Agile ways of working. My argument isn’t against Scrum. But I view Scrum as scaffolding, not a destination. Simply following any framework will not make you Agile.
Scrum Master duties should be thought of as responsibilities. Teams should be empowered to determine how best these responsibilities are addressed. For new teams it’s likely a person experienced in the Scrum Master role will be beneficial. But quickly the Scrum Master should be teaching others on the team their role.
Within a few Sprints the Product Owner should be facilitating Backlog Refinement, Sprint Planning and the Sprint Review. The Scrum Master should be teaching and mentoring the Product Owner to take on these responsibilities.
Similarly, the Scrum Master should be teaching the Developers to own both the Daily Scrum (often referred to as the Standup) and the Sprint Retrospective.
Over time teams may find that Scrum by-the-book is becoming limiting. They may discover the Daily Scrum is no longer necessary, especially if they are regularly pair programming or mobbing. In those cases they are likely talking as a group/groups most of the daily.
As teams get better at understanding their flow and using practices such as limiting work-in-progress (WIP) they may discover they no longer require the Sprint time box itself. Then events like Sprint Planning and Review will evolve into perhaps something like Replenishment (Kanban) and reviewing work as it completes rather than on a specific cadence.
Teams may also adopt something like an Andon Cord approach to issues where they stop and fix as issues are found rather than having a formal Retrospective on a cadence.
Wrapping Up
Likely this is an anti-pattern that organization’s stumble into rather than establish by design. With the industry-wide adoption of Scrum as the most used framework having the associated title is understandable.
Understanding that the Scrum Master is instead a role/accountability is a key concept. No one person needs to perform all the duties of a Scrum Master. Teams should be taught to own their ways of working and evolving beyond the need for a Scrum Master should be OK, perhaps even encouraged.
Teams will likely benefit from continued occasional coaching, targeted to a specific need. By embracing the kokoro, or heart, of Agile, greater effectiveness becomes possible. Removing Scrum Master as a title is one step in this direction.
If you liked this post and want to learn more about Agile, Lean or Leadership, please consider purchasing a book from my Recommended Reading page.
Until next time!
