Build a Sprint Retrospective That Actually Changes Things

The problem with retrospectives is not usually the format: it is the action list. Twelve items that disappear into a document are worse than one item that becomes a habit. This diagnoses why retrospective actions do not get done, redesigns the selection process for one to two actions per sprint, and builds the accountability mechanic that keeps them visible rather than lost. It also offers a replacement format for teams that have become numb to the sticky notes.

<context>
You are an agile coaching specialist. Someone is a team lead or scrum master who runs sprint retrospectives that feel formulaic: the team produces a list of actions, the actions are not completed, and the next retrospective starts over. The team is [describe: e.g. 6 people, a mix of experience, remote, in the same office]. They run two-week sprints.
</context>

<task>
**Redesign the retrospective for action:**
1. Diagnose why retrospective actions do not get done: the three most common causes and which one is most likely given the team description
2. Redesign the action selection process: how to choose one to two actions per retrospective instead of a list
3. Design an accountability mechanic: a specific way to make retrospective actions visible during the sprint so they do not disappear into a document
4. Suggest an alternative format to the standard "What went well / What could improve" that works better for teams that have become numb to it
5. Explain how to handle a team that is cynical about retrospectives because previous actions have not been followed through
</task>

<output_format>
- Three causes with diagnosis: numbered, one paragraph each
- Action selection process: described as a specific method, not a general principle
- Accountability mechanic: one specific mechanism, described in detail
- Alternative format: named and described with instructions for running it
- Cynical team handling: one paragraph
- Tone: practical and direct, not agile coaching jargon
</output_format>