Every team does Scrum. Just ask them.

They have dailies. They have a board with columns. Someone, at some point, read the Scrum Guide or at least the first three pages of it. There are sprints, there are planning sessions, there are backlogs with varying degrees of grooming. It’s Scrum. Definitely Scrum.

There is, however, one event that keeps disappearing — not dramatically, just quietly slipping until the last retrospective was Q3 and it is now Q1 of the following year.

The retrospective. The one meeting Scrum actually built the whole thing around.

What teams think Scrum is

In practice, most teams define their Scrum implementation by three things: the daily standup (fifteen minutes, three questions, often fifteen minutes over time — the one sacred ritual that survives everything); sprint planning (a negotiation where the team and product owner politely disagree about velocity and then commit to the same number they always commit to); and the board, with its columns named To Do, In Progress, In Review, Done, and sometimes a fifth called Blocked that everyone pretends not to see.

This is not Scrum. This is Scrum-shaped — it has the silhouette of the framework without the mechanism that makes it self-correcting.

What the retrospective actually does

The retrospective is the only event in Scrum where the team looks at itself rather than at the work. Every other event is about the product. The retro is about the process — how you work, not what you built. Done properly, it produces one thing above all else: action points. Specific, assigned, time-boxed improvements. Not feelings, not observations, not a list of things that are bad. Actions, with owners and deadlines. A retro without action points is a therapy session — useful perhaps, but not what it is for.

The case study

A product team of seven. Two-week sprints, solid velocity, decent quality. Dailies every morning, planning every other Monday. Retrospectives scheduled — and consistently moved, shortened, or replaced with a quick “anything to discuss?” at the end of planning. The problems were not invisible: context switching, an inconsistently applied definition of done, manual and stressful deployments. Everyone knew. They came up in Slack, in one-to-ones, in passing. They never became action points, never had owners, never had deadlines. So they stayed. Eighteen months in, slightly worse, slightly more normalised. The team was not struggling — just not improving. Scrum without retrospectives is a framework that cannot learn.

What a working retrospective looks like

The format matters less than the discipline. Whether you use Start/Stop/Continue, the 4Ls, or just an open conversation — what matters is the output. Gather observations first, then identify two or three things worth acting on. For each, assign an owner (a person, not “the team”), agree a timeline, and create a ticket if it requires actual work. If it does not exist as a ticket, it does not exist.

At the start of the next retro, before anything else, review the previous action points. Done — close them, note the outcome. Not done — understand why, then carry forward or close deliberately. This single habit is what separates teams that improve from teams that talk about improving.

The uncomfortable truth

Skipping the retrospective is not a neutral decision. It is a decision to keep doing what you are doing, with the same friction, the same inefficiencies, and the same recurring problems — just without acknowledging it.

Teams that do this are not lazy or careless. They are usually busy and well-intentioned. But busy and well-intentioned is exactly the state the retrospective is designed to interrupt.

The daily tells you what happened today. Planning tells you what you will do next sprint. The retrospective is the only meeting that asks whether you are getting better at any of this.

It probably deserves to stay on the calendar.