Engineering retrospectivesfor delivery, quality, and reliability
Connect delivery evidence with team context to improve flow, quality, reliability, ownership, and technical decision-making.
An engineering retrospective combines delivery evidence with the context only the team can supply. The goal is not to score developers. It is to improve the system around planning, review, testing, deployment, reliability, ownership, and learning.
Evidence worth bringing
- Work blocked by dependencies or environments.
- Pull requests waiting for review.
- Reopened items and escaped defects.
- Unplanned operational or support demand.
- Deployment failures and recovery friction.
- Knowledge concentrated in one person or service.
A 45-minute engineering retro
- Review the previous improvement and its signal.
- Set the sprint, release, or operational scope.
- Collect observations before showing metrics in detail.
- Use evidence to clarify patterns, not decide blame.
- Vote across delivery, quality, reliability, and team themes.
- Choose one controllable experiment with an owner and review date.
Useful formats
Classic Sprint is a balanced default. Sailboat separates momentum, drag, risk, and destination. DAKI helps redesign an engineering workflow, while Mountain Climber fits long migrations or platform milestones.
Keep the action testable
Replace “improve code review” with a bounded experiment: define the behavior, owner, duration, and evidence. If the issue is a specific failure, schedule a proper incident review rather than compressing causal analysis into a routine retro.