When Scrum Events “Don’t Work,” Scrum is telling you something.
The Scrum Guide makes a strong, causal claim:
“These events work because they implement the empirical Scrum pillars of transparency, inspection, and adaptation.”
Not might work.
Not should work.
They work — because of something very specific.
From the Cambridge Dictionary, “to work” means:
“to perform as intended and do what it is supposed to do.”
This is where many Scrum Teams get uncomfortable.
Because when people say:
“Our Sprint Review doesn’t work”
“The Retrospective feels useless”
“Daily Scrums are a waste of time”
They’re often blaming the event…
while the Scrum Guide points the finger elsewhere.
Working ≠ Busy
Working ≠ High Velocity
Working ≠ Full Calendars
In Scrum, “working” has nothing to do with activity.
Scrum Events work when:
- better decisions are made,
- learning actually happens,
- and behavior changes as a result.
If nothing changes after your events, they are not working — regardless of how engaged, efficient, or polite everyone was.
The Scrum Guide is explicit about the cause:
They work because they implement transparency, inspection, and adaptation.
Remove or weaken those pillars, and the events may still exist but they no longer work.
Some uncomfortable examples:
- Sprint Planning without real transparency → optimistic plans based on assumptions instead of evidence.
- Daily Scrum without inspection → status reporting instead of decision-making.
- Sprint Review without adaptation → feedback collected, politely ignored.
- Retrospective without psychological safety → superficial improvements that never change outcomes.
The event happened.
The calendar was respected.
Nothing improved.
That’s not Scrum failing.
That’s Scrum being ignored.
“The Event Is Broken” Is rarely the truth
When a Scrum Event doesn’t work, the more useful questions are:
- What is not transparent that should be?
- What are we not inspecting that matters?
- What are we not adapting because it feels risky or inconvenient?
Scrum doesn’t guarantee success.
It guarantees exposure.
If your events feel uncomfortable, awkward, or confrontational, that may be a sign they are finally starting to work.
A tough reflection...
Instead of asking “How can we improve this Scrum Event?”,
try asking:
- What truth is still hidden?
- What evidence are we avoiding?
- What decision are we postponing?
- What adaptation are we afraid to make?
Because Scrum Events don’t work by magic.
They work when empiricism is lived — not just scheduled.
And when they don’t?
Scrum is giving you data — not a defect report.
The question is whether you’re willing to look at it.
I’d love to hear your thoughts in the comments below!
I hope you find value in these short articles and if you are looking for more clarifications, feel free to make contact.
Don't want to miss any of these blog posts? Have the “The Scrum Guide Explored” series weekly in your mailbox.
Wishing you an inspiring read and a wonderful journey.
Scrum on!
