The Error-Friendly Retro 2.2.3-1

Purpose

The error-friendly retro is a scheduled team ritual designed to surface disagreement that social dynamics would otherwise suppress. It operates on the principle that if the team waits for dissent to emerge spontaneously, the team will wait forever — because the cost of volunteering disagreement in most team cultures exceeds the cost of staying silent.

This sidebar provides the operational template.

Format

Frequency: Weekly, biweekly, or at the close of a project cycle. The cadence should match the team's decision tempo — the faster decisions are made, the more frequently the retro should run.

Duration: 45–60 minutes. Shorter retros tend to rush the Update step, which is where the actual value is produced.

Facilitation: Rotate the facilitator. A permanently facilitated retro risks becoming the facilitator's meeting. Rotation distributes ownership and prevents the retro from being captured by a single perspective.

The Four Questions

What Did We Assume?

Each team member identifies one assumption that governed a decision during the review period. The assumption does not need to have been wrong — the purpose is visibility, not indictment. Assumptions are recorded on a shared document.

Prompt: "Name one thing we took for granted this [week/sprint/cycle] that we did not verify."

What Did We Learn?

The team identifies outcomes that matched and outcomes that did not match expectations. Mismatches are not failures. They are data points that reveal where assumptions were imprecise or conditions changed.

Prompt: "What happened that we did not expect? What did we expect that did not happen?"

What Should We Update?

Based on the gap between assumptions and outcomes, the team identifies specific changes — to a decision, a practice, a norm, or a plan. Each proposed update must be stated concretely: not "we should communicate better" but "we should add a midweek status check on the deployment timeline."

Prompt: "What would we do differently if we could rerun this [week/sprint/cycle]?"

Who Carries the Action?

Every update is assigned to a named person with a completion date. Unassigned updates are logged as open items and reviewed at the next retro.

Enforcement

The retro's value depends on two things: participation and follow-through.

Participation: The protocol works only if team members offer genuine disagreements rather than safe observations. The facilitator's role is to create the conditions for this — by going first with a substantive assumption, by explicitly inviting dissent from quieter members, and by ensuring that disagreement is met with reconstruction (the steelman-first protocol from the parent article), not rebuttal.

Follow-through: Open items from the previous retro are reviewed at the start of each new retro. If an update was assigned and not completed, the team discusses why — not to assign blame, but to determine whether the update was impractical, deprioritized, or simply forgotten. A retro that generates updates no one implements is disagreement theater (see parent article).

The Health Metric

Track one number over time: the update rate — the percentage of retros that produce at least one implemented change. A team with a consistently zero update rate is not practicing disagreement-as-data. A team with a consistently high update rate may be over-revising. The target is not a specific number. It is a pattern of honest correction — visible, tracked, and consequential.