On paper, being a Scrum Master means running ceremonies, keeping the board updated, and clearing blockers. That's the version you get from a certification course, and it's not wrong. However, in practice it means wearing a lot of different hats, and most of them have nothing to do with running a meeting.
I think the biggest misconception is that Scrum Masters primarily manage meetings and process. If there's a gap on the team, I fill it. If there's a communication issue, I jump in and help resolve it. Anything I can take off someone else's plate, I try to take on, whether that's supporting communications, organizing documentation, or tracking down data from one system or another. Ceremonies and removing blockers still matter, but the bigger part of the job is building the environment the team needs to succeed.
“Scrum gives you a strong framework, but real-world delivery rarely follows the textbook exactly. The value comes from knowing how to adapt it to what the team and client actually need.”
Absorbing the Noise
One of the harder parts of this job is making sure an urgent request doesn't automatically turn into a team-wide emergency. I've worked in more than one environment where incoming issues got labeled as needing an immediate fix before anyone had confirmed the impact. When that happens repeatedly, the team keeps getting pulled off planned work and forced to context-switch all day.
Protecting the team from that isn't about blocking the client or standing in the way of shifting priorities. It's about reducing unnecessary urgency and helping the business team absorb some of that ambiguity before it reaches the technical team. The team needs to understand why something matters to the client, but the client benefits from understanding what interrupting active work really costs the team, too. Sometimes something looks urgent on the first pass, and a closer look shows it only affects a handful of users, or doesn't need an immediate fix at all. Right now, we're working on formalizing intake and triage for both production work stoppages and regular service requests, so the business side can gather the facts and get clarity on priority with the client before the technical team gets pulled in.
Flexibility Over Perfection
I currently support an education-sector client, and that's forced me to rethink a lot of what "good" looks like in practice. Education clients operate around academic calendars, legislative deadlines, funding cycles, and enrollment periods, and none of that lines up neatly with a tidy two-week sprint. Something that felt like a priority during sprint planning can get overtaken almost overnight by a policy decision or an issue affecting people in the field. A good sprint, for me, isn't one that never changes. It's one where the team stays focused, understands why the work matters, and can adapt without losing quality, transparency, or momentum.
That same idea carries over into ceremonies. There are moments when Sprint Planning, Daily Scrum, Sprint Review, or Retro start to feel like we're doing them because the rules say we should, not because they're serving a purpose. When that happens, I shift my focus to why we're in the room instead of the textbook version of the meeting. Retro is the clearest example. With how much client work comes in and the team's limited capacity, I'm careful about asking people to spend another 30 to 60 minutes in a meeting unless that time will genuinely help them. It's become less about formally reviewing every sprint and more about checking in with the team: how's morale, what's weighing on people, is there anything I can change at my level to take some pressure off. Sometimes it's just a place for people to vent, and I think there's real value in that too. Daily Scrum has gone the opposite direction. The team gets real value from that check-in, so some days it's a ten-minute status update, and other days we spend the whole slot problem-solving something together. None of this means every ceremony happens the same way every time. It means the team has consistent chances to understand priorities, collaborate, and raise concerns. My goal was never to make the team fit Scrum perfectly. It's to make the parts of Scrum we use genuinely helpful.
The Limits of Scrum
A sprint rhythm is working when it gives the team a realistic window to focus and make progress toward something bigger. We can have several stable sprints in a row. Others fall apart when several urgent items land all at once. With a high volume of urgent work, things get harder to follow, and items can get lost if the process around them isn't intentional.
Part of the difficulty is structural. The same people responsible for planned sprint work on this team are also responsible for production issues and work stoppages. A developer might be making solid progress on a planned epic, then have to drop it immediately to support something in production. When that happens often enough, a two-week sprint starts promising a level of predictability the team doesn't really have. We've tried to account for it by reserving capacity for unplanned work, and that helps as long as the volume stays within range. But once urgent work goes past what we set aside, the sprint plan shifts anyway, whether we planned for it or not.
That's where I've started to see the real limits of Scrum in its strictest form, and why some of this work might be better supported through triage or a more continuous-flow approach instead. I know we've crossed the line from the sprint working for us to the team working around it when urgent requests routinely bypass planning and work keeps getting started and stopped. At that point, Scrum still helps, but more as a decision-making framework than a fixed commitment. It should support delivery. It's not supposed to become the goal itself.
Alignment Doesn't Mean Agreement
Education clients come with a wide range of stakeholders, and they don't always define success the same way. What I've learned is that alignment doesn't require agreement. It requires a clear, documented direction for the team to work from.
Our delivery team shouldn't be left to interpret competing priorities on its own. The client ultimately drives priority, and because those priorities can shift often, we focus on making decisions visible and documented instead of letting them get sorted out in silos. We're also strengthening our documentation and meeting regularly to review priority changes so that decisions are communicated to the right stakeholders, agreed upon, and not made in silos. That doesn't mean everyone agrees. It means there's one clear, documented decision about what matters most right now, even if that changes again next week.
The reality of the work rarely follows a perfectly predictable path, and I’ve stopped expecting it to. My job is to use the parts of Scrum that help, adapt the parts that don't, and keep the team moving even when the plan changes. That doesn't mean Scrum has failed; it means knowing when to adapt the framework is part of using it well.
Ready for Agile Built Around Your Team?
At The Canton Group, we bring that same flexibility to how we support our clients, adapting delivery frameworks to the realities of government and education-sector work instead of forcing a one-size-fits-all process.
