Most teams that say they “do Scrum” don’t actually do Scrum. They do something that looks like Scrum from the outside: the ceremonies are in the calendar, the terminology is correct, and the board has the right columns. But the underlying principle has been lost somewhere between the training and the day-to-day.
Scrum is not the calendar or the ceremonies.
Scrum is a system for turning learning into action quickly enough that the team can still do something useful with it.
Teams fall into the same trap with both Scrum and DORA metrics. They start doing the ceremony, measuring the metric, or copying the format, then assume the results will appear because the surface area looks correct.
But the practice is not the principle.
The ceremony is not the result.
The ceremony can survive after the point is gone
I saw this clearly at a healthcare SaaS provider. That was where I earned my CSM and CPO agile certifications, and more importantly, where I refined how I ran Scrum ceremonies so they added value instead of pageantry.
The team was not lazy. The engineers cared. The work mattered. The calendar had agile-shaped meetings on it.
But the product culture had a serious flaw: unless an entire massive feature was ready to ship, the work was treated as if it had no value. A feature could sit half-built while the team waited for the whole imagined version to become real. Then a louder customer would ask for something else, priorities would pivot, and the team would start another large thing before the previous large thing had taught anyone anything.
That is how you get Scrum activity without Scrum learning.
The fix was not a new ceremony. It was a different understanding of value. We started breaking work into smaller shippable pieces, introducing MVP thinking, and looking for slices that could reach customers early enough to produce feedback. Refinement went from roughly three stories in an hour to 13 to 15. Sprint planning went from assigning stories to developers and asking for estimates of remaining time to planning what feature would get worked on in the next two weeks. Under my direction, that team delivered 63 releases in 52 weeks and shipped a major reporting dashboard incrementally.
By the time that operating model settled in, planning for a two-week sprint averaged about 20 minutes. Not because we were careless. Because the work was already shaped, sliced, understood, and ready for a real commitment by the time the meeting started.
That is the difference between doing Scrum and understanding Scrum.
The point is not to perform the process. The point is to shorten the distance between learning and action.
Standup is coordination, not roll call
The daily standup is where many teams reveal the truth. If everyone takes a turn reporting to the manager, you do not have a coordination meeting. You have a daily status ritual.
A useful standup asks a different question: what is in the way of the sprint goal today? That changes the shape of the conversation. The team listens for dependency conflicts, blocked work, duplicated effort, and decisions that need to happen now instead of next week.
At the healthcare SaaS provider, we eventually moved Tuesday and Thursday standups async. Developers posted their updates in the main chat channel. I later brought the same practice to a financial services SaaS provider once the team had the rhythm and trust to use it well.
The purpose was to share the information, not perform the ceremony.
If nobody ever adjusts after standup, standup is not doing its job.
Review is where software meets reality
The sprint review is not a developer showcase. It is not an internal demo where the team shows each other what they already know.
The review exists because software does not create value until it touches reality. Stakeholders need to see working software, react to it, question it, and help shape what comes next. If the people who can validate the work are absent, distracted, or treated as passive spectators, the loop does not close.
This is where the healthcare SaaS dashboard work changed. Smaller releases meant customers and internal stakeholders could react to real pieces of the product instead of waiting for one giant unveiling. Feedback arrived while the work was still easy enough to shape.
At a financial services SaaS provider, I saw the other version of the same principle. My sprint demos regularly drew more than 30 people, including executives and members of other teams. The format worked well enough that other Scrum masters adopted it.
That did not happen because the ceremony was mandatory. It happened because the review created useful visibility.
That is review doing its job.
Retrospective is an accountability mechanism
A retrospective is not useful because people talked. It is useful because the team identified something worth changing and then changed it.
If the same three issues appear every retro, the ceremony is teaching the team the wrong lesson. Communication, documentation, and that recurring technical problem become background noise. People learn that improvement conversations are allowed, but improvement itself is optional.
The first question in a retrospective should be simple: what happened to the thing we said we would change last time?
If nobody knows, the retro is theater.
Planning is commitment to understood work
Sprint planning breaks down when it becomes a negotiation over points instead of a commitment to understood work. Stakeholders ask for more. The team pushes back. Everyone settles on a number that looks responsible enough to put in Jira.
That is not planning.
Planning should force clarity. What are we actually building? What does done mean? What assumptions are we carrying? What can we slice smaller? What would let us learn sooner?
The answer is not always “make the story tiny.” The answer is to make the commitment honest. A team cannot credibly commit to work it does not understand.
The manager’s role
The ceremony-without-principle pattern almost always has a management component. Teams notice what leaders reward. If leaders reward status, standup becomes status. If leaders reward impressive demos, reviews become theater. If leaders ignore retro action items, retros become complaint sessions. If leaders pressure teams into commitments before the work is understood, planning becomes fiction.
Managers do not have to run every Scrum ceremony. But they are responsible for the conditions around those ceremonies. They are also responsible for making sure the team does not confuse pageantry with progress.
Do stakeholders show up?
Do action items get support?
Can the team say “we do not understand this yet” without being treated as difficult?
Can the product owner accept a smaller release because the learning is valuable?
Those questions tell you more about Scrum maturity than whether the calendar has the right meeting names.
The honest assessment
Most teams do not need a new process. They need to understand the one they already claim to be using.
The ceremonies are not the methodology. They are mechanisms for generating feedback, surfacing problems, creating accountability, and helping the team course-correct before too much time has been spent building the wrong thing.
If the ceremony does not close a feedback loop, it is theater. It may be well-attended theater. It may be well-facilitated theater. It may look exactly like the process guide says it should look.
It is still theater.
Pick one ceremony. Name the feedback loop it is supposed to close. Then run it as if that feedback actually matters.
That is where Scrum starts becoming real again.