Engineering retrospectivesfor delivery, quality, and reliability
Bring delivery signals into the room, add the context behind them, and choose one change to improve flow, quality, or reliability.
An engineering retrospective combines delivery evidence with the context only the team can supply. Keep developer scores out of the session. Look at the system around planning, review, testing, deployment, reliability, ownership, and learning.
Bring evidence that helps explain the work
- Work held up by a dependency or environment.
- Pull requests sitting in the review queue.
- Reopened items and defects found after release.
- Operational or support work that interrupted the plan.
- Failed deployments and slow recovery.
- Knowledge held by one person or concentrated in one service.
A 45-minute engineering retro
- Start with the previous improvement and check its signal.
- Name the sprint, release, or operational period under review.
- Collect observations before showing the metrics in detail.
- Use the evidence to clarify a pattern and its surrounding conditions.
- Vote across delivery, quality, reliability, and team themes.
- Choose one change the team controls, then add an owner and review date.
Pick a format that fits the problem
Use Classic Sprint for a balanced review of a routine sprint. Sailboat maps momentum, drag, risk, and destination. Choose DAKI when an engineering workflow needs redesigning. Mountain Climber works well for a long migration or a platform milestone with several stages.
Write an action the team can test
Turn "improve code review" into a short trial with a named behavior, an owner, a deadline, and evidence the team can check. A specific failure deserves its own incident review, with enough time to understand the conditions that contributed to it.