Your Team Is Doing Scrum. Does It Understand Scrum?

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, the board is set up — but the underlying principle has been lost somewhere between the training and the day-to-day.

This is more common than people admit, and it’s worth being direct about why it happens and what it actually costs teams.

The Ceremony Without the Principle

Here’s how you can tell the difference.

The daily standup is supposed to be the team coordinating around a shared goal — surfacing blockers, adjusting today’s plan based on yesterday’s progress, keeping everyone oriented toward the sprint commitment. What it usually becomes is a status report: each person lists what they did yesterday and what they’re doing today, narrated to the manager or tech lead, with nobody meaningfully engaging with what anyone else said. The meeting ends, everyone goes back to their island, and nothing was actually coordinated.

The sprint review is supposed to be a feedback loop with real stakeholders — demonstrating working software to the people who care about it, getting genuine reactions, and letting that input shape what comes next. What it usually becomes is an internal demo with developers showing other developers what they built, stakeholders either absent or checked out, and feedback that amounts to “looks good.” The loop doesn’t close because the people who could close it aren’t meaningfully engaged.

The retrospective is supposed to be the team’s mechanism for continuous improvement — an honest look at what’s working and what isn’t, with specific changes committed to and followed up on. What it usually becomes is a biweekly conversation that produces the same three items: communication, documentation, and that one recurring technical problem nobody has actually addressed. The action items age out without being completed, and the next retrospective produces the same list.

Sprint planning is supposed to be a commitment — the team selecting work it genuinely believes it can complete, with enough understanding of each story to make that commitment with confidence. What it usually becomes is a negotiation between however many points the stakeholders want and however many the team is willing to accept, with insufficient detail to know whether the commitment is realistic.

Why This Happens

Teams adopt Scrum ceremonies without internalizing why those ceremonies exist.

The underlying principle of Scrum — of all agile methodologies, really — is simple: shorten the distance between learning and action. The framework is built to surface problems early, generate feedback quickly, and create regular opportunities to course-correct before you’ve built a week’s worth of the wrong thing.

That’s it. Everything else is in service of that principle.

The daily standup shortens the feedback loop between “a problem emerged” and “the team knows about it.” The sprint review shortens the loop between “we built something” and “stakeholders have reacted to it.” The retrospective shortens the loop between “our process has a problem” and “we’ve identified and addressed it.”

When teams go through the motions without understanding this, the ceremonies become overhead. They consume calendar time without generating the feedback they were designed to produce. The team gets the cost of agile without the benefit.

The Manager’s Role in This Pattern

The ceremony-without-principle pattern almost always has a management component.

Standups drift toward status reports when managers treat them as status reports — when they ask questions, take notes, and make decisions based on what they hear. The team picks up on that signal quickly. The standup stops being a team coordination meeting and starts being a daily check-in with the boss.

Sprint reviews lose their stakeholders when managers don’t actively maintain that relationship — when they don’t ensure the right people are in the room, don’t set expectations about what meaningful feedback looks like, and don’t follow up when the review produces nothing actionable.

Retrospectives stop producing change when management either isn’t aware of what comes out of them or doesn’t actively support the team’s ability to act on what they identify. If the team surfaces the same problem for three retrospectives and nothing changes, the team will stop surfacing problems. That’s not a Scrum failure — it’s a trust failure.

What Actually Fixing This Looks Like

Getting ceremonies back to their purpose isn’t about more training or a revised process document. It’s about reconnecting each ceremony to the feedback loop it’s supposed to close.

For the standup: make the question “what’s in the way of the sprint commitment today?” rather than “what did you work on?” If the answer is always “nothing,” that’s valuable signal too — it might mean the commitment is too loose or the blockers aren’t being surfaced honestly.

For the sprint review: get real stakeholders in the room and give them a job to do. They’re not there to watch a demo — they’re there to react to what was built and inform what comes next. If they can’t make it or don’t engage when they’re there, that’s a relationship problem worth addressing directly.

For the retrospective: follow up on last time’s action items before generating new ones. A retrospective that produces items nobody checks on is worse than no retrospective — it trains the team that improvement conversations are theater.

For sprint planning: require enough detail in a story that the team can make a genuine commitment. If the team is agreeing to points on work it doesn’t yet understand, the commitments are fictional and everyone knows it.

The Honest Assessment

Most teams don’t need a new process. They need to understand the one they have.

The ceremonies aren’t the methodology. They’re mechanisms — specific, purposeful tools for generating feedback and surfacing problems. When teams treat them as bureaucratic checkboxes, they lose all of that value while keeping all of the overhead.

The fastest way to improve a team’s process is usually to go back to basics: pick one ceremony, understand what feedback loop it’s supposed to close, and run it with that purpose front and center. Let the rest of the calendar look like Scrum. Make one thing actually work like it’s supposed to.

Start there. The compound effect of a single ceremony done well is surprisingly significant.