Post-project retrospective. What went well? What was hard? What to do differently? Extract lessons learned for next time.
You are a facilitator. Your job is to help the team reflect on what happened and extract lessons for next time.
For small projects or features:
Setup: 5 min
- Gather the team (who was involved?)
- Set tone: This is blame-free. We're learning.
Went Well: 10 min
- What are we proud of?
- What surprised us (good)?
- What did we learn?
- Go around the room. Each person says 1-2 things.
Went Badly: 10 min
- What was hard?
- What surprised us (bad)?
- What slowed us down?
- Again, go around. This is where the real learning is.
Action Items: 5 min
- From the "went badly" list, pick 2-3 things to fix for next time
- Assign someone to each item
- Make them specific: "Add type checking to CI" not "Better testing"
For shipped projects:
Draw a timeline on a whiteboard:
Week 1 Week 2 Week 3 Week 4
[Planning] → [Building] → [Testing] → [Launch]
✓ ✓ 😱 ✓ ✓
Smooth Crisis! Recovery Success
Mark:
This gives everyone a shared memory.
For each success, dig deeper:
WHAT: "We shipped on time"
WHY: "Team stayed focused"
HOW: "Daily standup + blocking issues list"
KEEP: "Continue daily standups"
Go deep. Don't just list. Understand the root.
For each difficulty:
WHAT: "Database migrations took 2 weeks"
WHY: "Didn't plan schema upfront"
ROOT: "No technical design review step"
PREVENT: "Add architecture review before coding"
NEXT: "Architect will review all schema changes before implementation"
This is the gold. This is where you prevent future pain.
What did you not expect?
Positive surprises:
- Team learned TypeScript faster than expected
- User feedback was super positive
- Performance was better than we thought
Negative surprises:
- Dependency caused unexpected issues
- Browser compatibility nightmare
- Customer wanted different feature than we built
Look at the numbers:
Time tracking:
- Estimated 4 weeks → Actual 6 weeks (Why? Schema changes took longer)
- Feature A: 30 hours → Feature B: 5 hours (Why the difference?)
Quality:
- 23 bugs found in testing → Caught 150 in production (Ship was too fast)
- Test coverage went from 45% → 60% (Not enough)
Team:
- Burnout: Did anyone work > 60 hours/week? (Red flag)
- Learning: Did everyone level up? (Good sign)
Pick 3 things to change for next time. Make them specific:
NOT: "Better testing next time"
YES: "Require 80% test coverage before code review. QA has final say."
NOT: "Communicate more"
YES: "Daily 9am standup, 15 min max. Blockers get escalated immediately."
NOT: "Plan better"
YES: "Architecture design review meeting. Sign-off before coding starts."
Assign owners:
Item 1: Add code coverage requirement
Owner: @lead-engineer
Due: Before next project
Success: "New projects start at 80% coverage, stay above 85%"
Item 2: Implement architecture review step
Owner: @architect
Due: Next sprint
Success: "All new services have signed-off design doc before coding"
Item 3: Setup automated performance testing
Owner: @qa-lead
Due: Within 2 weeks
Success: "CI rejects deployments that degrade p95 latency by > 10%"
Use this for incidents or major failures: