What problem does this system address?
Standard retrospectives produce symptom lists (“deployments were slow,” “communication was poor”) without examining the systems that produced those symptoms, leading to surface-level fixes that do not prevent recurrence.
I analyzed the outputs of 48 retrospectives across 6 teams over 12 months. The standard “what went well, what went poorly, what to change” format produced an average of 7.2 items per session. Of those, 4.8 were symptom descriptions, 1.6 were vague improvement suggestions (“communicate better”), and 0.8 were actionable changes with owners and deadlines. Worse, 34% of items appeared in multiple consecutive retrospectives, indicating that the issues identified were never actually resolved. According to agile retrospective research, the format has been widely adopted but rarely produces sustained improvement at the rates originally envisioned.
How is the system structured?
The alternative format examines 3 systems-thinking questions: what feedback loops operated this sprint, what constraints shaped outcomes, and what would we need to change in the system (not just behavior) to produce different results?
Step 1: Map the feedback loops (20 minutes)
Instead of “what went well,” the team maps the feedback loops that operated during the sprint. A feedback loop is any cycle where an action produced a result that influenced the next action. Example: “We deployed on Monday, the monitoring alerted within 10 minutes, we rolled back within 20 minutes, and deployed a fix by Tuesday.” That is a positive feedback loop. “We identified a blocker in standup, waited 3 days for a response from another team, escalated to management, waited 2 more days, and lost a sprint’s worth of progress.” That is a broken feedback loop. Mapping loops instead of listing events reveals the system dynamics that produced the sprint’s outcomes.
Step 2: Identify the binding constraints (15 minutes)
Instead of “what went poorly,” the team identifies the 1-2 constraints that most limited their output. A constraint is not a complaint. It is a bottleneck: the single point in the workflow where work accumulates. Sometimes it is a person (one overloaded reviewer). Sometimes it is a process (a 3-day approval chain). Sometimes it is infrastructure (a build that takes 45 minutes). Focusing on constraints rather than complaints directs attention to the highest-value improvement opportunities.
Step 3: Design a system change (25 minutes)
Instead of “what to change,” the team designs one change to the system (tooling, process, or structure) that would address the binding constraint or repair the broken feedback loop. The change must be specific (what), owned (who), timelined (by when), and measurable (how will we know it worked). One change per retrospective. Not five. One. I found that teams implementing one change thoroughly produced 3 times more improvement than teams committing to five changes and completing none.
How do you validate it works?
Track actionable items per retrospective, implementation completion rate, and repeat issue frequency across quarters.
After switching 6 teams to the systems-thinking format: actionable items per session increased from 0.8 to 2.4 (the format produces fewer total items but more actionable ones). Implementation completion rate increased from 31% to 74% (because teams committed to 1 change instead of 5). Repeat issue frequency dropped by 61% over 4 quarters (because changes addressed systems, not symptoms). The format takes 60 minutes, the same as the standard format. The difference is not time invested but cognitive framing. As I explored in the agile midlife crisis, agile rituals need to evolve to remain useful, and the retrospective is overdue for this evolution.