Leave the retrospective with one test

Read the diagram as text

Use one observed event, choose a small experiment with an owner and agree what evidence to review next. Return to that evidence at the next retrospective.

A retrospective can feel productive and change nothing. Its useful output is a decision somebody can act on and revisit. Instead of collecting a long improvement backlog, take one recurring observation and design a small test around it. Preserve the other observations for later rather than pretending the team can act on all of them at once.

Bring the work into the room

Ask participants to bring a recent item, handoff or decision they can describe. An account of what happened is easier to investigate than a label such as “communication.” Give people a way to raise a concern without disclosing personal information to the group. Do not require a public story about an individual to demonstrate engagement.

The Agile Manifesto includes regular reflection followed by adjustment. The meeting format below is our editorial proposal for turning that intention into a checkable team experiment. It is not a required ceremony or a validated scoring system.

A compact facilitation sequence

1. Recall: list observed events from a bounded period.
2. Clarify: separate what happened from possible explanations.
3. Select: choose one issue the group can influence.
4. Design: agree on a change, owner and expected mechanism.
5. Review: decide which evidence will inform the next decision.

Allow more time for clarification when accounts conflict. A facilitator should not settle a factual disagreement by voting on the more popular explanation. Keep the uncertainty and agree on an observation that could resolve it.

Illustrative test

Suppose an imaginary team repeatedly discovers missing acceptance details during testing. It proposes a brief review of the next few requests before implementation. The owner records which details were clarified, whether the review delayed urgent work and whether testing still surfaced the same gaps. The example has no claimed success rate because no real trial has been performed.

“Hold more meetings” would be too vague. “For the next suitable requests, the requester and tester review the acceptance example together before implementation” describes an action and a mechanism. Agree on what “suitable” means so people do not quietly exclude difficult cases after seeing the result.

Make the decision reversible

Set a point at which the group can modify or stop the change. A trial should not become permanent merely because nobody remembers who authorized it. If the change adds work, record what it replaces or how the additional burden will be reviewed. Invite the people affected outside the immediate team to contribute.

Open the next retrospective with the previous test

Ask what was actually tried and what was learned. A missed experiment needs a discussion of feasibility, not a fabricated outcome. If the evidence is mixed, say which observations conflict. The group can narrow the test or collect more comparable examples before concluding that it helped.

Observation:
Working explanation:
Change to try:
Owner and affected people:
Evidence to gather:
Review date:
Decision after review:

Use the A3 worksheet when the selected issue needs deeper problem framing. Read the archived Learning to Learn note for the earlier discussion. A small, documented learning cycle is easier to inspect than a growing list of promised improvements.