I once dabbled in project management. Then I found Agile, and I worked hard to say the world of project management goodbye. Structure-heavy schedules, Gantt charts, control disguised as communication, bickering over billable hours. I traded all that in for servant leadership, flow, and emergent design. Or so I thought.
Because here I am again. Circumstances have conspired to pull me back into that balancing act: Agile Coach and Scrum Master by design, project manager by necessity. In the final 1% of a struggling project, with the outcome hanging by a thread, I did things that would make a Scrum fundamentalist weep. I reserved Sprint capacity. I asked for daily updates. I monitored progress with a level of scrutiny that I rarely acknowledge.
And of course, nothing energises a purist, more Roman than the Pope, more than a chance to question authority. Especially the kind that dares call itself a Scrum Master while not actually doing Scrum.
I get it. But this is not cosplay. It’s not a game governed by rules. Sometimes it is about making hard choices to deliver real value. People and interactions over processes and tools. That includes Scrum too.
It has been a long time since I considered myself a purist, or, as I call it, the Scrum Police. I am a pragmatist. I value _realpolitik_ over dogma. To know the rules deeply, to know what it means when you break them, and still choose to do so for the greater good is a sign of maturity. That is a form of mastery.
Rules and the reason behind them
Scrum’s guidelines are intentionally prescriptive. Roles, events, and artefacts. All of it built to work in unison. And the moment you touch one part, a purist appears to explain that you are no longer really doing Scrum.
There is a reason for the strictness. Scrum’s simplicity is deceptive; it is, as the Guide itself warns, challenging to master without discipline. Sticking closely to the framework when you are new to it represents the Shu stage of Shu-Ha-Ri learning, where you follow the form until it becomes second nature. Shu-Ha-Ri entered the agile vocabulary via Alistair Cockburn, who borrowed the stages from Japanese martial arts to describe practitioner progression from imitation (Shu) through adaptation (Ha) to innovation (Ri). You have to know the thing before you can bend the thing.
What experienced Scrum Masters eventually learn is that no single framework fits every situation. Practice should serve outcomes, not the reverse. Advanced practitioners move through Ha into Ri, still anchored in principle, still empirical, but no longer spooked by the idea that adapting a ceremony is a betrayal. Scrum realists, not Scrum purists.
The framework invites this directly. Empirical process control rests on transparency, inspection, and adaptation. If the retrospective keeps telling you that a particular practice is slowing the team down, pragmatism is not heresy. It is Scrum doing what Scrum says it does.
Principles over prescriptions
Deviating from ‘pure’ Scrum can feel like betraying Agile. Usually it is the opposite. The Agile Manifesto is older than Scrum’s current shape and broader than any one framework: individuals and interactions over processes and tools, responding to change over following a plan. The manifesto never names Scrum. It never names anything. Scrum is one way to live out those values, not the only way.
Valuing individuals over processes is a direct encouragement to be pragmatic. If the Daily Scrum has rotted into a status report that nobody needs, the Agile move is to fix the event so it serves the people, not to preserve the ritual so it punishes them. Responding to change applies to process plans as much as product plans. The plan to run Scrum by the book is itself a plan. Reality will arrive and ask you about it.
The framework has already inspected and adapted itself several times. The 2020 Scrum Guide quietly retired the three Daily Scrum questions, renamed Development Team to Developers, and reframed what the Scrum Master is actually accountable for. If Schwaber and Sutherland can change the Guide, your team can change its implementation.
A word of caution. Pragmatism is not a license to drift. Agile values continue to serve as a guiding principle, and the crucial question to consider before making any adjustments is: which option best prioritizes customer focus, team health, and adaptability?” A decision made against the compass, consciously, is very different from one made by accident.
Pragmatism when the going gets tough
The real test of a pragmatic scrum master is not in a steady state. It is in a crisis. A deadline is about to crater. A production incident that pulled the whole squad out of the Sprint at 3am. The moments where the book is least useful.
In those moments your first job is to help the team get through the storm and still deliver what the business needs. Sprint timeboxes shorten. Planning becomes daily, sometimes hourly. The rule of “no changes mid-Sprint” is politely suspended because priorities are now shifting by the hour. A purist will say you must formally abort the Sprint; the pragmatic move is often exactly that, because the Sprint cancellation mechanism exists for the moment when the Sprint Goal becomes obsolete.
There is another shift that makes purists uncomfortable. In a crisis, an experienced Scrum Master will often lead more directly than usual. Fewer open questions, more “here is what we are doing next.” This is not a betrayal of servant leadership. Servant leadership means giving the team what they need at that moment, and what a team needs in a crisis is clarity. In Cynefin terms, a true crisis maps to the Chaotic domain, where the correct response pattern is “act, sense, respond.” Facilitation-heavy behaviour is appropriate in the Complex domain; it can be actively harmful in Chaotic conditions.
What matters just as much is what happens after. Once the fire is out, the reflection has to be deliberate. A special retrospective. An honest conversation with the Product Owner and management about the root causes that produced the emergency in the first place. “Pragmatic” is not the same as “permanently chaotic.” If you dropped Reviews and Retrospectives for a month to survive, you bring them back with more weight, not less. Otherwise, the exception quietly becomes the new norm, and the team stops inspecting anything at all.
Mastery is knowing when to break the rules
Mastering Scrum does not mean mastering the rules. It is mastering when to apply them and when to adapt them. That is what separates a certified Scrum Master from an effective one.
Pragmatism, done properly, is disciplined. It is not “Scrum when it’s convenient.” It is knowing the rules so well that you understand the intent behind each one and the cost of changing them and then changing them anyway, out in the open, with the team, as an experiment you can inspect. That is a very different posture from winging it and calling it Agile.
Abandoning the values that make Agile work (transparency, inspection, adaptation, trust, collaboration) is where real damage happens. The framework is a means, not the end. If a tweak helps your team deliver value, run it as an experiment. Use retrospectives and data to check whether it helped. Roll it back if it did not work. Being pragmatic is itself an Agile behaviour: responsiveness in the one place it actually matters, which is how you work.
Teams and organizations evolve. Markets shift. A Scrum Master who is too rigid may keep the label pure while failing the team in front of them. The alternative is a principled pragmatist: someone who can guide a team through storms and unfamiliar territory, adjust the sails, and keep the ship pointed at the true north of Agile values.
I am proud to call myself one. In the complex reality of product delivery, that stance has served my teams and my stakeholders considerably better than dogma ever did.