A team's retrospectives end in complaints and no owned action. How would you fix that?
answer
- Complaints are not yet improvements
- Cap the output, name one owner
- Safety decides what gets said aloud
- Open the next one with the last action
basics
~20 sEnd every retrospective with at most two improvements, each with one named owner and a place in the next iteration's work. Then fix safety, because a team that cannot name the real problem out loud will only ever list symptoms.
solid answer
~40 sDiagnose which failure you actually have. If nothing is decided, the meeting needs a point where generating stops and choosing starts. If improvements are decided but die, fix the mechanics: cap the output at one or two, give each a single named owner, size it to finish inside the next iteration, and put it in the team's real work rather than in a document. Then open the next retrospective by checking those items - that habit alone moves completion rates, because an action that will be asked about in public gets done. If the same surface topic recurs while the real cause stays unnamed, the problem is safety, not process: change who is in the room, gather input silently before discussion, and start from data rather than feelings.
go deeper
Know what the meeting is for - improving how the team works, rather than reporting on what it did - and know that an improvement with no named owner is very unlikely to happen at all.
Be able to describe the mechanics that make an action survive: cap the number, name one owner, size it to fit the iteration, put it where the work is visible, and review it at the start of the next retrospective.
Demonstrate facilitation judgement. Talk about how you get an uncomfortable problem named - who is in the room, data before opinion, silent gathering first - and about the one visible fix that proved to the team that speaking up paid.
Own the systemic half. Much of what a team surfaces is not the team's to fix, so describe how those items get carried, tracked and answered, and what repeatedly ignoring them does to a team's willingness to speak at all.
## Three different failures with the same symptom "The retrospective produces no owned action" describes at least three distinct problems, and they need different fixes. 1. **Nothing is decided.** The hour fills with observations and the meeting ends when the clock does. This is usually a facilitation gap: no moment in the meeting separates generating ideas from choosing between them. 2. **Something is decided and nobody does it.** Improvements are recorded as intentions — "we should communicate better" — owned by everybody, sized like a project, and stored in a document nobody opens again. 3. **The real problem is never said out loud.** The team discusses flaky builds for the fourth time while the actual cause — a dependency on a group that never answers, or a lead whose changes skip review — goes unnamed. This one is invisible from outside, because the meeting looks productive. The first is a process fix, the second a mechanics fix, the third a safety problem. Working out which one you have is half the answer. ## Making an improvement survive the meeting - **Cap the output at one or two.** A list of eight is a wish list. Capacity is the binding constraint: the team has to fit the improvement inside the same iteration as its committed work. - **Name a person, not a group.** "The team will..." has no owner. One name, chosen in the room, said out loud. - **Put it where the work is.** An improvement living in a separate document competes with work living on the team's work board, and loses every time. Make it an item with a size, like anything else. - **Make it observably finished.** "Improve code review" cannot complete. "Add a rota so no change waits more than one working day for review" can. - **Open the next retrospective with the previous action.** Two minutes, every time. This single habit does more than any format change, because an action that will be asked about in public tends to get done. - **Size it to one iteration.** If it cannot finish before the next retrospective, it is a project and it needs the same treatment as any other project. | Symptom | Likely cause | First move | |---|---|---| | Long list, nothing finished | No cap, no owner, no size | Cap at two, name owners, size them | | The same topic every time | The real cause is upstream or unsayable | Change who is in the room; start from data | | Silence in the meeting | Cost of speaking exceeds the benefit | Gather input silently before any discussion | | Actions owned by "the team" | Responsibility diffused across everyone | One name per improvement, said aloud | | Attendance drifting away | Nothing has visibly changed in months | Finish one uncomfortable item publicly | ## Getting the real problem named Safety is not a mood; it is a set of costs the team can read accurately. People say the unsayable when saying it is cheap and looks useful. - **Check who is in the room.** Anyone who writes performance reviews changes what will be admitted, however good their intentions are. - **Start from data, not feelings.** How many items carried over; how long the oldest unfinished item has been in progress; how many changes waited more than a day for review. Numbers make a problem discussable without accusing a person. - **Gather before you discuss.** Silent or anonymous collection first, then group the input together. That removes the cost of being the first person to say something. - **Ask about the system.** "What made this hard?" gets a different answer from "who missed this?" - **Rotate or neutralise facilitation.** A facilitator with a stake in the outcome shapes it whether or not they intend to. - **Open with an assumption of good faith.** The widely used convention, often called the prime directive, of stating up front that everyone did the best they could with what they knew at the time is a small ritual that reliably lowers the temperature. ## When the improvement is not the team's to make A great deal of what a team surfaces is genuinely outside it: a shared environment nobody owns, a dependency on another group, a date fixed elsewhere. Asking the team to generate actions for these teaches learned helplessness very quickly. Record them separately, name the person who will carry each one to whoever can act, and report back at the next retrospective — including when the honest answer is "no movement". A tracked, unanswered problem is tolerable. An untracked one ends attendance. ## What good looks like A seven-person team on an allotment-management service produced fourteen improvements across six retrospectives in the run-up to a conference-timed release; three were ever done. Nothing about the format changed — only the mechanics. At most two improvements per session, one named owner each, each one an item in the next iteration's work, and two minutes at the start of the following retrospective to check them. Completion went from three in fourteen to eleven of twelve over the next quarter. The meeting had never been the problem. Its output had no owner and no capacity.
- What if the biggest problem the team names is outside its control?Then do not ask the team to fix it. Record it separately, name the person who will carry it to whoever can act, and report back at the next retrospective - including when the answer is no movement. Repeatedly generating actions a team is not allowed to take is how a retrospective teaches learned helplessness, and it is the fastest way to lose attendance.
- How do you get a real problem named when the team has learned not to say it?Change what it costs to say. Gather input silently or anonymously before discussion, start from data rather than feelings, ask about the system instead of the person, and check who is in the room. A neutral or rotating facilitator helps. So does the team watching one uncomfortable item actually get fixed, which is the only durable proof that speaking up was worth it.
- How many improvements should one retrospective produce?One or two that will finish before the next one. A list of eight is a wish list: it survives as a document and dies as a change. Capacity is the binding constraint, because the improvement has to fit inside the same iteration as the team's committed work, so size it accordingly and cut the rest.
A retrospective with no owned action is a fire alarm that nobody is required to answer: it still rings, and people stop hearing it.
saying these in an interview costs you the question
- Thinks the retrospective's purpose is letting people vent
- Leaves actions owned by the team rather than one person
- Produces eight improvements each time and finishes none
- Assumes silence in the room means there are no problems
- Asks the team to fix constraints it cannot change