Running a retrospective that produces changes, not lists

Goal

Leave the meeting with a small number of concrete changes that will actually be made before the next retrospective, rather than a wall of sticky notes that nobody reads again.

Prerequisites

A fixed cadence (end of each iteration or every two to four weeks), the whole team present, the action list from the previous retrospective, and a facilitator who is not the manager. The Scrum Guide describes the retrospective as the event where the team inspects the last Sprint with regard to individuals, interactions, processes, tools and its Definition of Done, timeboxed to at most three hours for a one-month Sprint.

Steps

1. Open by reading the Prime Directive aloud: regardless of what is discovered, everyone did the best job they could given what they knew, their skills, the resources and the situation. It is a working assumption that keeps the discussion on the system, not on persons.
2. Review last time's actions first. For each: done, not done, or dropped, with one sentence why. An action that has been "in progress" twice is dropped or re-scoped now.
3. Gather data before opinions: incidents, carried-over items, review wait times, interruptions. Five minutes of silent writing, then cluster.
4. Pick one theme by dot vote. Discuss only that theme; park the rest with a note.
5. Ask for the mechanism, not the blame: what made this outcome likely? What would have to be different for it not to recur?
6. Formulate at most two actions. Each has an owner (one person), a due date before the next retrospective, and an observable completion criterion ("the flaky test list is empty", "the deploy checklist has a rollback step"). Actions that only say "be more careful" are rejected.
7. Put the actions where the work lives: in the backlog or the next iteration plan, as the Scrum Guide suggests, not in the meeting notes alone.
8. Close with a one-minute check: was this meeting worth its cost? Adjust the format next time if not.

Expected result

A short, visible list of changes with a completion rate that the team can see over months; recurring themes become obvious because they resurface in step 2.

Limits and test basis

Teams under acute pressure will skip the meeting; it is better to shorten it than to cancel it. Problems outside the team's authority need an escalation, not an action item. The procedure is a synthesis of the cited sources and common practice; no completion rate is claimed.