The Retro — blameless, or pointless.

Of all the agile ceremonies, the retrospective is the one most teams treat as optional when they're under pressure. It is also the one whose absence does the most quiet damage. Stand-ups can be skipped for a week. Planning can be done badly in fifteen minutes. Demos can be rescheduled. None of those omissions changes the team's trajectory. Skipping the retro for a quarter does, because the retro is the only meeting whose entire job is to make the next sprint better than the last one. Without it, every team's effective ceiling is the practices they walked in with.

That's the upside. The downside is that a retro done badly is worse than no retro at all. It teaches the team that the meeting is theatre, that nothing changes, and that speaking up is risky. Most retros that get ditched were ditched for that reason, and the team was right to ditch them. The fix isn't more retros. It's a retro that's structured, blameless, and followed up on. Three things, all of them learnable, none of them difficult, and almost none of them happening on the teams that need them most.

What a retro is.

A retrospective is a structured reflection at the end of a sprint, milestone, project, or quarter. The standard scrum cadence puts one at the end of every sprint. It typically runs sixty to ninety minutes, the whole delivery team in the room (or call), no stakeholders unless explicitly invited. The output is a short list of things the team will do differently next time. That is the entire deliverable. Not a written report. Not a culture survey. Three to five action items, owned, due-dated, visible.

The format varies. The rule that matters does not. Without psychological safety in the room (without the explicit, enforced commitment that nothing said here will be used against anyone) the meeting becomes a piece of corporate Kabuki where people repeat the same safe observations week after week, and nothing changes. That single rule is the load-bearing structure. Everything else is choice of layout.

The four formats that work.

I'd recommend keeping four in the toolkit and rotating between them. Rotating matters. Running the same format every sprint trains the team to give the same answers. Different scaffolds prompt different reflections. The four worth knowing, all of which you'll find variants of at FunRetrospectives:

Start, Stop, Continue. Three columns. The team writes practices to start, things to stop, and things working well enough to continue. It is the workhorse — forward-looking, action-oriented, easy to convert into next-sprint commitments. If you only learn one format, learn this one.

Mad, Sad, Glad. Three columns, organised by feeling. People write what frustrated them, what disappointed them, what they celebrate. Use this after a hard sprint, a failed release, a difficult quarter. The format gives explicit permission to bring emotion into the room, which a process-shaped format suppresses. Use sparingly; if every retro is Mad/Sad/Glad, the team starts performing emotions.

The 4Ls. Liked, Learned, Lacked, Longed For. Four columns. Reflective rather than tactical, best at the end of a release, a milestone, or a longer programme of work. It surfaces capability gaps ("Lacked") and ambition ("Longed for") that the more action-shaped formats miss.

Sailboat. A visual format — a boat, with wind behind, anchors below, rocks ahead, and an island as the destination. The team places sticky notes against each. It looks gimmicky and is the best of the four for quarter-end strategic retros, because it forces a conversation about the actual goal, not just the last fortnight's process noise.

The one rule: blameless.

Without psychological safety, every format produces the same output: the safe observation, the political answer, the silence where the real issue was. The team that runs Sailboat without blamelessness will name "communication" as an anchor. The same team with blamelessness will name "the executive who keeps reprioritising mid-sprint", which is actionable, and which "communication" never is.

Blamelessness is mechanical, not cultural. You enforce it by saying out loud, every retro, that the meeting is blameless. By treating any individual blame in the room as a facilitation interrupt: the facilitator names it and redirects. By writing the action items in the system-level voice ("our sprint planning under-scoped because we don't include the security review") rather than the person-level voice ("Sarah forgot security"). And by following up. Retros where action items get tracked and closed reinforce the rule; retros where they vanish quietly teach the team that speaking up costs them.

Rotate the facilitator.

The scrum master or product manager facilitating every retro is a common pattern and a quiet bad one. It centres the meeting on one voice, makes it harder for that voice to participate, and slowly trains the rest of the team to be passive. A rotating facilitator (pick the next engineer, designer or PM in the team and brief them on the format a week in advance) moves the meeting from a thing that happens to the team to a thing the team runs.

It also surfaces capability. The engineer who facilitates well is the one you'll later want as a tech lead. The designer who can hold the room is the one who'll grow into a product role. The retro is a low-stakes facilitation reps machine. Use it.

The "action items that never close" anti-pattern.

This is how most retros die. The team identifies three things to change. They are added to a board or a doc. Two weeks later, the next retro begins, and either nobody mentions the last set of actions, or they are read out and quietly noted as "still in progress." After four or five cycles of that, the team correctly concludes that the retro doesn't change anything, and attendance drifts.

The fix is to track actions where the team works: a column in the team board, a pinned message in the channel, a recurring check at stand-up, not a retro doc nobody opens between retros. Each action has an owner (one person, not "the team"), a due date inside two sprints, and a visible status. The first ten minutes of every retro reviews the previous actions before the team writes new ones. Closed actions get celebrated. Open ones get explicitly re-owned or explicitly dropped. The third option, "still in progress, vaguely", is what kills retros and is the one to refuse out loud.

When to skip a retro: never.

The pressure to skip is highest exactly when the retro is most valuable. The sprint that ran off the rails. The release that slipped. The week where the team is exhausted. Those are the retros that produce the most learning, because the team has the clearest data on what didn't work and the most motivation to change it. Skipping the retro after a bad sprint is paying for the experience and then not collecting it.

If you absolutely must compress, shorten the format to thirty minutes, one format, three action items, but hold the meeting. The signal that the team protects retros under pressure is worth more than any single retro's output.

How we use this at Product Pieces.

When we partner with a team and the symptom is "the same problems keep coming back," the retro is usually the missing artefact: either skipped, run as theatre, or used for blame rather than learning. We don't try to fix the retro by adding ceremony. We strip back to the structure: one format, rotated facilitator, three actions, all owned, all due-dated, all tracked where work lives. Three sprints of that and the team's compound rate of improvement is visibly different. Not because the meeting changed, but because the meeting now produces change.

If your team has stopped running retros, or runs them and shrugs at the output, the gap isn't enthusiasm. It's the rule that holds the meeting together, and the plumbing that closes the loop.

Next issue: N°06. Definition of Ready, Definition of Done. The two checklists that prevent half the arguments.