There's truth in both Hiten Shah's words and your own. There is one aspect of the scrum master role that is essential: that of a change agent. Organisations wishing to improve the way they work need someone to focus wholly on that improvement. Not on product, not on technology, not on people-management, only on improvement—in all its forms: personal, relational, environmental. Without such a person, who would hold the big picture there is a danger of local optimisation, and great disconnect. A good scrum master (there are painfully few) would focus on this. It may be better to rename the person who does this though, and separate it from Scrum. Scrum itself may be going down the drain, but don't throw the baby out with the bathwater!
I find the Scum framework incredibly compelling. It’s so simple and straightforward in its totality. You strategise, you plan, you execute, you inspect daily, you review the outcome, you review your practices, repeat.
There is something truely wonderful about how easy that concept is to grasp, and how almost universally this seems to be something we all can get behind.
Yet, we see time and again an application of Scrum often yields disfunction. We end up as the piece says, with zealots who stick to some text book definition. There is this lack of flexibility and adaptability which is wholly ironic, and when everything is Scrum nail all the problems need a Scrum hammer.
I’m a Project Manager, and I’m heavily leveraging what I’ve learned from my Scrum training. However I’m not banging on about Agile and Scrum. I’m picking the parts that work in our context (at least that I think work).
What I do not understand is, what parts of the process are broken. I can appreciate that perhaps, the Scrum Master role is too narrow. We don’t need a meeting facilitator on all our teams so to speak (slightly unfair to the role, but it’s typically how it plays out).
But do we not want teams to regularly iterate, to present working product, to get feedback, check alignment with the strategy, then carry on? What is the alternative?
That’s not a defence of Scrum or the Scrum Master role, that’s a philosophical one. Because the problem has been that organisations plan to death, thinking they are derisking, get caught in the contract game, and end up with massive cost blow outs and hopelessly late and cancelled projects.
So while we are saying fhe Scrum Master is dead, maybe we should say the Project Manager is dead too? Schedules are stupid, they never work. They give you a false sense of confidence, you spend endless hours updating them, only for you to roll your eyes knowing it’s a waste of time.
Scope documents are dumb too. We spending hours labouring over a scope document, feeling great about ourselves, knowing the whole time that there will be scope creep, the organisation will change and the environment will too. We know all of these documents will change. Yet the purpose of them is to draw boxes and say “that’s done”. But it’s clearly not, and everyone knows it.
So while we say agile is dead and Scrum is dead, tell us what problems still exist and what should be done?
I find it interesting how some “dump” on things touting that it’s a failure but provide no alternatives or solutions. I find that it undermines and invalidates the very suggestion it makes of “failure!”
1. There already are many alternatives and solutions out there.
2. Something can be a failure, and there can be no alternative solution. One has no bearing on the other. So it does not invalidate or undermine anything.
3. I don't just dump, I've written hundreds of practical articles and posts.
I’m curious if “something better than Scrum” will suffer the same fate. Won’t dogmatically implementing any framework lead to similar issues, when following the process is placed above delivering value?
You're spot on, yet the problem is many frameworks have dogma baked in.
Especially Scrum does a poor job of conveying the intent behind the rules, while many people do know some of the rules.
IMO, the rules never matter, what they are supposed to help you with matters. And if you understand that, you don't need the rule as you can derive it from first principles.
Agree with the points you’re raising. If Scrum masters do much more than remember the rules, then no wonder they’re not achieving results. And if they can, there are many roles that someone understanding dev processes and ways of working can fulfill, so they may be promoted out of the team quickly. Being able to think from first principles is highly sought-after
The thing is the work that the scrum master does is important work to do. It has to be done somewhere, and if a scrum master is not doing it then who is? And if no one is doing that work, I promise the team is not very efficient. The work that a scrum master does is very nuanced and hard to explain succinctly.
Having been a Scrum Master for many years, from L.A. to Seattle and elsewhere, currently in San Francisco…there is a reason so many SM roles are temporary!
In my experience, as suggested above, as a contractor…you’re a contractor for a reason and not in a good way! They need someone who is more or less, as far as a client is concerned, a non-entity, vulnerable and has NO ONE to vouch for them; a contractor who often must take on the ENTIRE organization from the CIO down to teams you are ostensibly trying to help.
Most orgs push the “servant leader” designation too far! In most cases in my experience, Agile Scrum at least is seen as an a la carte menu, not truly a framework. In addition, most end up taking the Scrum framework and basically recasting it into something that is nearly unrecognizable and in the end is a figment of their imagination, in one instance, a director created his own “Fibonacci sequence” of 1-8 sequentially, the purpose of which was to help accounting track work hours, or use sprint planning as an opportunity to write epics, and in the end, the sprint backlog had 83 items…I kid you not!
It’s not the Scrum Masters who are necessarily the problem (as with anything incompetence exists) but the deceptive hiring practices that have dominated the industry. If I had a “nickel “ for every interview where the hiring manager/s couldn’t tell me why they wanted to “do Scrum” or define “success” for a new Scrum Masters…I could retire.
When left to do my job as a SM, stakeholders have usually been very pleased and in some cases amazed at the seeming ease of sprint development compared to …,say, Waterfall!!
Adam thanks for sharing your article. I understand it provides overview of other frameworks. The question which your article doesn’t answer for Kanban framework example is that what is the Scrum Master equivalent role in this setup?
It's my opinion that teams should select their processes and decide how they will be managed. Creating pre-defined roles that must be fit onto every team, regardless of their unique circumstance, is one of the big ways that Scrum went wrong.
I see your point. I’ve seen Scrum Masters adding 0 value to some teams and still being attached to that team because “every team needs a Scrum Master” policy adherence.
But I’ve also seen teams benefiting from good Scrum Mastery or Coaching. I don’t see how deleting that role serves every team on earth.
Optionality is a good way to leave things at. Let those who can benefit from the dedicated role keep benefiting
That makes sense. I could see the scrum master role morphing into a more generic agile coaching role. And if each team can decide it's own processes, then they would have agile coaches at their disposal to give them advice.
There's truth in both Hiten Shah's words and your own. There is one aspect of the scrum master role that is essential: that of a change agent. Organisations wishing to improve the way they work need someone to focus wholly on that improvement. Not on product, not on technology, not on people-management, only on improvement—in all its forms: personal, relational, environmental. Without such a person, who would hold the big picture there is a danger of local optimisation, and great disconnect. A good scrum master (there are painfully few) would focus on this. It may be better to rename the person who does this though, and separate it from Scrum. Scrum itself may be going down the drain, but don't throw the baby out with the bathwater!
This is what I struggle with. A job search for change agent has turned up no roles named this way. 😅
[Voice of God, movie trailer tone]
Just when you thought the Scrum Master was gone…
buried beneath org charts, layoffs, and abandoned Jira boards…
AI brings it back.
Faster. Smarter. Terrifyingly calibrated.
No ceremonies. No stickies.
Just a sentient risk engine wrapped in servant-leader nostalgia.
It doesn’t ask for blockers.
It predicts them—then quietly reassigns your roadmap.
Coming soon: The Return of the Scrum Master
Now 82% prompt-tuned…
and absolutely not the scrum-bot you were looking for.
I find the Scum framework incredibly compelling. It’s so simple and straightforward in its totality. You strategise, you plan, you execute, you inspect daily, you review the outcome, you review your practices, repeat.
There is something truely wonderful about how easy that concept is to grasp, and how almost universally this seems to be something we all can get behind.
Yet, we see time and again an application of Scrum often yields disfunction. We end up as the piece says, with zealots who stick to some text book definition. There is this lack of flexibility and adaptability which is wholly ironic, and when everything is Scrum nail all the problems need a Scrum hammer.
I’m a Project Manager, and I’m heavily leveraging what I’ve learned from my Scrum training. However I’m not banging on about Agile and Scrum. I’m picking the parts that work in our context (at least that I think work).
What I do not understand is, what parts of the process are broken. I can appreciate that perhaps, the Scrum Master role is too narrow. We don’t need a meeting facilitator on all our teams so to speak (slightly unfair to the role, but it’s typically how it plays out).
But do we not want teams to regularly iterate, to present working product, to get feedback, check alignment with the strategy, then carry on? What is the alternative?
That’s not a defence of Scrum or the Scrum Master role, that’s a philosophical one. Because the problem has been that organisations plan to death, thinking they are derisking, get caught in the contract game, and end up with massive cost blow outs and hopelessly late and cancelled projects.
So while we are saying fhe Scrum Master is dead, maybe we should say the Project Manager is dead too? Schedules are stupid, they never work. They give you a false sense of confidence, you spend endless hours updating them, only for you to roll your eyes knowing it’s a waste of time.
Scope documents are dumb too. We spending hours labouring over a scope document, feeling great about ourselves, knowing the whole time that there will be scope creep, the organisation will change and the environment will too. We know all of these documents will change. Yet the purpose of them is to draw boxes and say “that’s done”. But it’s clearly not, and everyone knows it.
So while we say agile is dead and Scrum is dead, tell us what problems still exist and what should be done?
This is exactly how I feel and you have articulated it much better than I did.
Scrum has become an accountability sink.
What should be done?
I find it interesting how some “dump” on things touting that it’s a failure but provide no alternatives or solutions. I find that it undermines and invalidates the very suggestion it makes of “failure!”
Thanks for your question.
I'm a bit baffled by your comment.
1. There already are many alternatives and solutions out there.
2. Something can be a failure, and there can be no alternative solution. One has no bearing on the other. So it does not invalidate or undermine anything.
3. I don't just dump, I've written hundreds of practical articles and posts.
I’m curious if “something better than Scrum” will suffer the same fate. Won’t dogmatically implementing any framework lead to similar issues, when following the process is placed above delivering value?
You're spot on, yet the problem is many frameworks have dogma baked in.
Especially Scrum does a poor job of conveying the intent behind the rules, while many people do know some of the rules.
IMO, the rules never matter, what they are supposed to help you with matters. And if you understand that, you don't need the rule as you can derive it from first principles.
Agree with the points you’re raising. If Scrum masters do much more than remember the rules, then no wonder they’re not achieving results. And if they can, there are many roles that someone understanding dev processes and ways of working can fulfill, so they may be promoted out of the team quickly. Being able to think from first principles is highly sought-after
The thing is the work that the scrum master does is important work to do. It has to be done somewhere, and if a scrum master is not doing it then who is? And if no one is doing that work, I promise the team is not very efficient. The work that a scrum master does is very nuanced and hard to explain succinctly.
It's a really easy question to answer.
Lots of companies work without Scrum Masters. And without problems.
The work is necessary because Scrum claims it is necessary.
Oh so scrum masters are making up work when they go to work? The work they are doing isn’t actually necessary?
I love Carrie Printernerter!
Having been a Scrum Master for many years, from L.A. to Seattle and elsewhere, currently in San Francisco…there is a reason so many SM roles are temporary!
In my experience, as suggested above, as a contractor…you’re a contractor for a reason and not in a good way! They need someone who is more or less, as far as a client is concerned, a non-entity, vulnerable and has NO ONE to vouch for them; a contractor who often must take on the ENTIRE organization from the CIO down to teams you are ostensibly trying to help.
Most orgs push the “servant leader” designation too far! In most cases in my experience, Agile Scrum at least is seen as an a la carte menu, not truly a framework. In addition, most end up taking the Scrum framework and basically recasting it into something that is nearly unrecognizable and in the end is a figment of their imagination, in one instance, a director created his own “Fibonacci sequence” of 1-8 sequentially, the purpose of which was to help accounting track work hours, or use sprint planning as an opportunity to write epics, and in the end, the sprint backlog had 83 items…I kid you not!
It’s not the Scrum Masters who are necessarily the problem (as with anything incompetence exists) but the deceptive hiring practices that have dominated the industry. If I had a “nickel “ for every interview where the hiring manager/s couldn’t tell me why they wanted to “do Scrum” or define “success” for a new Scrum Masters…I could retire.
When left to do my job as a SM, stakeholders have usually been very pleased and in some cases amazed at the seeming ease of sprint development compared to …,say, Waterfall!!
Curious about what are your ideas about something better. Can you also explore the solution side of the problem you described in this article?
Here are a few of the ideas I've come up with: https://rethinkingsoftware.substack.com/p/the-many-alternatives-to-scrum
Adam thanks for sharing your article. I understand it provides overview of other frameworks. The question which your article doesn’t answer for Kanban framework example is that what is the Scrum Master equivalent role in this setup?
Sounds like a happy mature world 🤝
It's my opinion that teams should select their processes and decide how they will be managed. Creating pre-defined roles that must be fit onto every team, regardless of their unique circumstance, is one of the big ways that Scrum went wrong.
I see your point. I’ve seen Scrum Masters adding 0 value to some teams and still being attached to that team because “every team needs a Scrum Master” policy adherence.
But I’ve also seen teams benefiting from good Scrum Mastery or Coaching. I don’t see how deleting that role serves every team on earth.
Optionality is a good way to leave things at. Let those who can benefit from the dedicated role keep benefiting
That makes sense. I could see the scrum master role morphing into a more generic agile coaching role. And if each team can decide it's own processes, then they would have agile coaches at their disposal to give them advice.