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 tracked progress with a sharper eye than I usually care to admit.
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 is not a game of rules. It’s sometimes about making hard choices to deliver real value. People and interactions over processes and tools—and that includes Scrum too.
It’s been a long time since I considered myself a purist, or as I call it, the ‘Scrum Police‘. I am a pragmatist at heart. 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—that is a form of mastery too.
Scrum Masters often find themselves caught between two imperatives: upholding the Scrum framework to the letter and ensuring their team delivers value under real-world conditions. The Scrum Guide presents Scrum as an immutable framework – any omission or alteration means “the result is not Scrum”. In practice, however, strict adherence can sometimes clash with on-the-ground needs.
In this blog post, I would explore whether pragmatism—the ability to adapt and bend the rules when necessary—should be considered a core skill for Scrum Masters. Using the lens of the Agile Manifesto’s values (especially valuing “individuals and interactions over processes and tools”), I will examine the tension between doing what’s by the book and doing what works.
Rules and the reason behind them
Scrum’s official guidelines are intentionally prescriptive. The framework defines roles, events, and artifacts meant to work in unison, and many practitioners—or purists—insist that any deviation dilutes its effectiveness. These purists argue that if any part of Scrum is altered or omitted, then it isn’t ‘true’ Scrum.
Early in one’s Scrum journey, it’s common to treat the Scrum Guide as gospel, implementing every event and rule exactly as described. This strictness has a rationale: Scrum’s simplicity is deceptive, and it can be ‘difficult to master’ without discipline. Adhering closely to the framework at first (the “Shu” stage of Shu-Ha-Ri learning) helps teams learn the fundamentals before they start improvising.
However, experienced Scrum Masters eventually recognize that no system is perfect, and no single framework fits all situations. A method is only as good as the value it delivers. Advanced practitioners who reach the “Ha” and “Ri” stages of mastery embrace intuition and innovation, even if it means breaking the shackles of the status quo. They transition from Scrum purists to what we might call Scrum realists – those who still deeply understand Scrum principles but are willing to adjust practices pragmatically. This balancing act is not about abandoning Scrum’s core ideals, but about applying them in service of outcomes rather than enforcing dogma.
The Agile principle of ‘inspect and adapt’ guides this outlook. After all, Scrum is based on empirical process theory, to be transparent, inspected, and adaptive. If our retrospectives and observations tell us that a certain Scrum practice isn’t helping (or worse: is hindering) our team, a pragmatic Scrum Master will consider adjusting it.
Agile ‘purity’ should focus on adhering to values and principles, not rigidly enforcing every ritual. In the end, the Scrum Master’s dilemma often boils down to: “Do we follow the rules, or do we do what works”? Advanced Scrum Masters realize these are not mutually exclusive. Scrum can be flexible. If something isn’t working, you might consider incorporating elements from other frameworks both within Agile and outside. In other words, Scrum provides a baseline, but pragmatic leaders skillfully extend it.
(Agile) principles over prescriptions
Deviating from ‘pure’ Scrum can feel like betraying Agile, yet often it is actually in service of Agile principles. To untangle this, it helps me a lot to return to the Agile Manifesto, the bedrock of Agile philosophy. The manifesto’s values include “individuals and interactions over processes and tools” and “responding to change over following a plan.” Notice that it doesn’t say “always follow the Scrum Guide?” In fact, the manifesto never mentions Scrum or any specific methodology—Scrum is just one way to embody Agile. Agility is bigger than just Scrum. What matters most are the core values and principles that help teams deliver value and improve.
Valuing individuals and interactions over processes and tools is a direct encouragement to be pragmatic when needed. It implies that people’s needs and effective collaboration come first, and the process serves those, not the other way around. So if a strict Scrum rule or ceremony is not working for the team—perhaps Daily Scrums have become stale and aren’t fostering interaction, or the rigid Sprint structure is causing stress—an Agile mindset would favor adjusting the process to better support the individuals, rather than sacrificing the people to preserve the process.
Similarly, consider “responding to change over following a plan.” Usually we apply this to product requirements, but it can just as well apply to our process plans. If the ‘plan’ is to follow Scrum by the book, then responding to change might mean altering that plan when reality shifts. If the context shows that the Scrum framework itself (the current process plan) isn’t the right tool for the job, then being Agile might mean pivoting to a different approach (maybe Kanban, maybe something else?).
That’s a radical example, but it underscores a crucial point: Agile allegiance is to outcomes, values, and principles, not to any one framework.
Of course, there’s a balance to strike. The Agile Manifesto doesn’t imply ‘anything goes’ or that we should change our process whimsically. Rather, it provides a compass for decision-making when we face gray areas. A Scrum Master with a pragmatic mindset uses Agile values as their North Star. When deciding whether to enforce a rule or bend it, they should ask themselves: “Which course of action aligns better with our values of customer focus, team health, and adaptability?” If, for example, skipping a Sprint ceremony this once will help the team focus on delivering a critical fix and better satisfy the customer, then it may well align with ‘customer collaboration’ and ‘responding to change.’ They would make that choice consciously, and later reflect on it.
In practice, teams that evolve their process tend to keep the Agile spirit intact. They still value (virtual) face-to-face interactions, still produce working increments frequently, still engage customers, and still inspect and adapt regularly. The difference is simply that they don’t treat the Scrum Guide as an inflexible decree.
The fact that multiple versions of the Scrum Guide have been published is proof that the framework is not static perfection. For example, the guidance around the Daily Scrum questions was loosened in 2020, something that would have been unthinkable for a purist a few years prior! If Scrum’s own creators can inspect and adapt the framework, surely Scrum Masters and teams can do the same with their implementation of it.
The key is that they do so in a thoughtful, principled way, always aiming to improve outcomes. Agile purity should focus on values and principles – those are too often lost when people get purist about methods. In short, sticking rigidly to a methodology is not the point – delivering value and fostering a healthy, high-performing team is! Pragmatism guided by the Agile Manifesto helps Scrum Masters achieve that, whereas blind adherence can sometimes lead them astray.
When the going gets tough: pragmatism during a crisis
Perhaps the ultimate test of a Scrum Master’s pragmatism is how they respond during a crisis. These are moments when clinging to the rulebook can be especially counterproductive.
Consider a crisis scenario: a major deadline looms but the team is far behind, or a critical production defect is causing severe outages. In these high-pressure situations, the Scrum Master’s first responsibility is to help the team navigate the storm and deliver what’s needed for the business. This might entail breaking some usual Scrum norms. For example, in a crunch to meet an immovable deadline, a team might temporarily decide to bypass parts of the Scrum process. Sprint timeboxes could be thrown out or shortened drastically, and planning might shift to a daily or even real-time mode. The normal rule of ‘no changes during a Sprint’ might be suspended because the reality is that priorities are shifting daily to address the crisis.
A Scrum purist might insist that “we must either stick to the Sprint or formally abort it,” but in the fog of crisis, such formality can feel like a hindrance. The pragmatic Scrum Master keeps a cool head and focuses on outcomes over rituals. They might even vouch for an early end to the Sprint (an official Sprint cancellation) if that helps re-plan and refocus the team on the urgent goal, using the Scrum mechanism designed for when sprint plans become obsolete.
More subtly, an advanced Scrum Master will often step up with more directive leadership than usual during a crisis. Under normal conditions, the Scrum Master acts as a facilitator and coach, guiding the team to self-organize. But when the house is on fire, it may not be …the best time for a purely facilitative stance. A pragmatic Scrum Master might explicitly re-prioritize work with the Product Owner on the fly, rally the team around a new action plan, or take on coordination tasks (even if that edges into project manager territory) to make sure nothing falls through the cracks. Such behavior might surprise those who believe a Scrum Master should never deviate from servant leadership. Yet in a crisis, servant leadership can mean doing whatever the team needs from you at that moment – even if it’s outside your typical role.
Just as important is what happens after the crisis. Once the urgent threat is resolved or the deadline met, the Scrum Master guides the team in reflecting on what happened. Maybe they conduct a special Retrospective to capture lessons. The idea is to acknowledge that the normal process was bent (or broken) out of necessity and to ensure this doesn’t quietly become the new norm. Pragmatic does not mean permanently chaotic.
For instance, if the team dropped Sprint Reviews and Retrospectives for a month to cope with a crunch, the Scrum Master should bring them back as soon as possible once stability returns, perhaps even with greater emphasis on why they matter. They might also work with management to address root causes – e.g. how can we avoid last-minute scope changes that lead to crisis mode? In this way, the crisis-driven pragmatism is treated as an exception, a one-off adaptation that helped the team survive a tough time. The experience often then feeds improvements: maybe the Definition of Done is strengthened or testing is increased to reduce production bugs, etc.
An advanced Scrum Master uses the crisis to advocate for change that prevents future emergencies, effectively saying, “We don’t want to have to break Scrum next time; let’s fix the underlying issues.”
Throughout crises, Agile values remain a compass. In a crisis, “responding to change” is obviously paramount—you throw out the plan and do what’s needed. A pragmatic Scrum Master keeps sight of why we’re doing Agile in the first place: to deliver value faster, to satisfy customers, to build engaged teams, and to handle change gracefully. They will bend any specific Agile practice if it means better achieving those ends in that moment. And after bending, they will regroup and realign with the core principles, ensuring the team continuously learns and improves.
Balanced pragmatism is mastery in motion
In the journey from novice to expert, a Scrum Master comes to learn that mastering Scrum is not just about mastering the rules—it’s about mastering when to apply them and when to adapt them. Pragmatism, in this context, is not a betrayal of Scrum’s values but rather an embodiment of them. By staying true to the Agile spirit (delivering value, fostering collaboration, and embracing change), advanced Scrum Masters often find that a little flexibility with the framework goes a long way. The ability to discern when to be strict and when to be flexible is what distinguishes a merely certified Scrum Master from a truly effective one. In short, a Scrum Master who blends pragmatism with principle is often more effective than one who rigidly clings to the Scrum rulebook.
To be clear, pragmatism as a core skill doesn’t mean an advanced Scrum Master throws out Scrum when it’s inconvenient or becomes some kind of ad-hoc manager. Rather, it means they cultivate situational awareness, good judgment, and a deep understanding of Agile principles. They know the Scrum rules well—so well that they understand the intent behind each and the consequences of changing them. This allows them to deviate with purpose, not by accident or ignorance. When they do modify Scrum practices, it’s done openly, with the team’s buy-in, and often as an experiment with a feedback loop. In other words, their pragmatism is itself disciplined and reflective.
For fellow Scrum Masters and Agile practitioners, the takeaway is this: the art of Scrum lies in knowing when to follow the playbook and when to write a new play.
We should never abandon the values that make Agile work—transparency, inspection, adaptation, trust, and collaboration—but we must remember that the Scrum framework is a means to an end. If a tweak or an exception helps your teams deliver value and improve, consider it honestly. Use retrospectives and data to verify if it helped, and don’t be afraid to roll back if it didn’t. By being pragmatic, you are modeling one of the greatest Agile strengths: responsiveness.
Ultimately, pragmatism enables resilience. Teams and organizations evolve, markets shift, and no two projects are identical. A Scrum Master who is too rigid may keep the ‘Scrum’ label pure but fail the team when novel challenges arise.
In contrast, the advanced Scrum Master, armed with a pragmatic mindset, can guide their team through storms and unfamiliar territory—adjusting the sails while keeping the ship aimed at the true north of Agile values. This ability to balance orthodoxy with reality—to be a principled pragmatist—is what elevates a Scrum Master from good to great. It’s why pragmatism should be seen as a core competency for advanced Scrum Masters who are leading teams in the real world.
I am proud to call myself a principled pragmatist. And in the complex reality of product delivery, that stance has served my teams—and my stakeholders—far better than dogma ever did.