How do you run a retrospective that actually changes something, and what do you do when the team has stopped engaging with them?

Define the output before you design the meeting

A retrospective's output is not a list of observations, a mood board, or a page in Confluence. It is one improvement, with a named owner, small enough to finish inside the next Sprint, that goes into the next Sprint Backlog as work. The Guide says the team identifies the most helpful changes and may add them to the Sprint Backlog, and that clause is doing more work than it appears to. An improvement that consumes no capacity is an improvement nobody scheduled, and unscheduled improvements lose to features every single time.

So the design constraint runs backwards from that. Whatever activity you choose has to converge, and most retrospectives fail at convergence rather than at generation. Teams are generally good at producing twenty sticky notes and poor at reducing twenty to one. Budget your hour accordingly: roughly fifteen minutes gathering data, twenty generating insight into the two or three items with real signal, and a hard twenty at the end on the decision. If the last twenty minutes get eaten by discussion, you have run a venting session.

The other constraint is size. "Improve our test coverage" is not an action; it is a wish with no first move. Compare two versions of the same outcome:

Weak:   "Improve code review turnaround."           owner: the team    when: ongoing
Usable: "Add a #reviews-needed Slack channel and a
         rule that any PR open >24h gets posted
         there. Try for one Sprint, review at the
         next retro."                                owner: Dan        when: Sprint 34, 2 pts

The second one is falsifiable. At the next retrospective you can ask whether it happened and whether it helped, and both questions have answers. That is the whole mechanism.

Getting past the polite version of the truth

Teams routinely surface the third-most-important problem, because it is the safe one. The build is flaky, the ticket template needs a field, the standup is a bit long. The real item — a senior engineer whose reviews are demoralising, a Product Owner who changes scope on Thursdays, a manager who overrode the team's estimate — goes unsaid.

Two practical moves help more than any named technique. The first is bringing data rather than opening the floor. Put last Sprint's actual numbers on the screen: five items carried over, cycle time up from four days to eleven, three of eight stories blocked on the platform team. Data licenses a conversation that nobody has to volunteer to start, and it makes the important topic the obvious one. The second is asking for the timeline rather than the opinion. Walk through the Sprint day by day and mark where work stalled; the pattern usually identifies itself, and describing an event is far easier than accusing a person.

On attendance, be direct with the interviewer: the retrospective is for the Scrum Team. If a line manager sits in and the team goes quiet, that is not a facilitation puzzle to be solved with a clever format, it is a structural problem, and the answer is a private conversation with the manager about what the meeting is for and what they get instead — a summary of the chosen improvement and any impediment that needs them. Interviewers notice whether you are willing to have that conversation.

When the team has stopped engaging

Start from the assumption that disengagement is rational, because it almost always is. A team that shrugs through retrospectives has usually learned that the meeting has no consequences. Before changing the format, go back through the last four or five retros and count how many agreed actions were completed. If the answer is one out of eleven, you have your diagnosis and no icebreaker is going to fix it.

The distinctions worth making, because the remedies are different:

• Learned futility. Actions were agreed and nothing happened. Fix by closing the loop visibly: pick one old commitment, complete it before the next retro, and open that retro by saying so. Then cut to one action per Sprint so the completion rate becomes credible.
• Fear of consequence. People know the problem and will not say it in the room. Fix by gathering input in writing beforehand, or one-to-one, and bringing the themes yourself so no individual is the source. Also check who is in the room.
• Everything the team raises is outside its control. Environments, a shared dependency, a release gate. The team is right, and the format cannot help. Your job here is to carry the impediment upward with evidence, and to report back — including when the answer is no, because an honest no restores more credibility than silence.
• Genuine boredom. The team is functioning well and the same format has run forty times. Vary it, lengthen the cadence, or occasionally retrospect on one theme in depth rather than the whole Sprint.

What not to do is worth stating too, since candidates reach for it: do not respond to disengagement by mandating attendance or adding energisers. Both read as a facilitator treating the symptom, and a team that has correctly concluded the meeting is pointless will find them slightly insulting.

There is also a case for stopping temporarily. If the team is genuinely blocked on one large external impediment, running a fortnightly meeting to re-notice it is a waste of an hour. Suspending retros for a Sprint while you go and work the impediment, with an explicit agreement to resume, is a defensible answer that shows you value the outcome over the ceremony — provided you actually go and do the work.

The thing that separates the two answers

Almost every candidate can name three retrospective formats. Very few can describe the mechanism by which a retrospective's output competes for capacity against a feature, and that is the distinction being probed. Improvements that live in a separate "improvement backlog", or that are owned by "the team", or that carry no Sprint and no size, do not happen — not because anyone is lazy, but because a piece of work with no owner and no slot loses to work that has both. Getting one improvement into the Sprint Backlog every Sprint, and being willing to spend the points, is unglamorous and is the entire difference between a team that improves and a team that meets.