Retrospective
How to turn a retrospective into reusable learning by comparing expectations with reality, identifying gaps, extracting lessons, and changing future behavior.
Retrospective is not a project recap
Chronology helps memory, but learning requires understanding why expectations and reality diverged.
Start with Expectation
What did the team originally believe about scope, timing, users, dependencies, effort, or risk?
Framework: Expectation → Reality → Gap → Learning → Next Behavior
Expectation — what did we expect?
Reality — what actually happened?
Gap — where was the important difference?
Learning — what reusable principle or insight emerged?
Next Behavior — what will we do differently next time?
Gap matters more than blame
A gap may come from a wrong assumption, missing process, hidden dependency, or slow decision.
Look for system patterns, not a person to blame.
Learning should go beyond “be more careful next time”
Good learning is specific enough to reuse.
“Validate before visual production begins” is stronger than “communicate better.”
Next Behavior turns learning into operating change
Add checkpoints, change sequence, update templates, define Done, adjust cadence, or clarify decision rights.
Learn from what worked too
Successful behaviors should also be captured so they can be repeated deliberately.
Retrospectives need evidence
Use timelines, decision logs, blocker history, metrics, feedback, and artifacts rather than memory alone.
Applying this on Forwork
Forwork can include a Retrospective Block: Expectation, Reality, Gap, Root Cause, Learning, Keep, Change, Next Behavior, Owner, Related Evidence.
Learning can become Tips, project patterns, or process templates.
Conclusion
Do not only ask, “What did we learn?”
Ask: “What behavior will this learning change in the next project?”
Expectation → Reality → Gap → Learning → Next Behavior.