From Dogma to Pragmatism: The Scrum Master’s Balancing Act

At a client site, I observed a well-meaning leader insist that the Daily Scrum must be run “by the book.” 

Each developer had to answer the three questions in order: 

  1. What did you do yesterday? 

  2. What will you do today? 

  3. Any blockers? 

Within minutes, eyes glazed over. Developers rattled off updates as if they were status reports, not conversations. The Scrum Master, eager to stay “true to Scrum,” did nothing to adapt. 

What was meant to be a moment of collaboration turned into a ritual no one valued. By the end of the Sprint, attendance was dropping, and the Daily Scrum had become just another boring meeting, which I am sure sounds familiar to some of you.


What.

This is the difference between mechanical Scrum and principled pragmatism. Mechanical Scrum rigidly follows the exact wording or form of practices without considering whether they actually serve their purpose. Pragmatic Scrum Masters, on the other hand, base their actions on core principles: empiricism, transparency, and focus, and adapt practices to support those goals.

The framework is purposely lightweight to promote flexible, context-specific applications. A Daily Scrum isn’t intended to be a status update; it’s meant to help the team adjust its plan to achieve the Sprint Goal. 

If answering three questions accomplishes that, great. If not, modify the format because the principle, not the ritual, is what truly matters.


So What.

Dogmatic application of Scrum erodes trust and engagement. When teams feel forced into ceremonies that add no value, they disengage, and disengagement is far more dangerous than imperfect practice. As John Kotter reminds us in Leading Change, lasting change requires buy-in, not compliance. Rituals done for ritual’s sake create the illusion of agility while undermining its spirit.

Scrum Masters who enforce rules without context may unintentionally become the very “process police” critics rail against. This perception damages not just the role, but Scrum itself, fueling the “Agile is dead” narrative we see online.


Now What.

The task for Scrum Masters is to flex wisely:

  • Always return to principles, ask, “What is the purpose of this event or artifact?”

  • Experiment with formats that fit the team’s context while protecting Scrum’s integrity.

  • Invite the team into adaptation: “How might we run this in a way that helps us meet our Sprint Goal?”

Pragmatism is not about bending until Scrum disappears; it’s about adapting practice while protecting principle. The Scrum Master serves as the guide who ensures this balance is maintained.


Let's Do This!

Scrum Masters who cling to dogma lose teams. Scrum Masters who flex without principles lose Scrum. 

The best Scrum Masters walk the line: adapting practices to context while holding fast to the principles that make agility possible. In complex systems, there’s no single recipe. The art of the Scrum Master is knowing when to flex, when to hold firm, and how to make agility real.