Continuous Improvement
The retrospective is the engine
Continuous improvement is process-level inspect and adapt. The retrospective closes every iteration, but its format should vary - Start/Stop/Continue, the 4Ls, sailing ship, or a data-driven review of cycle time and defects - so the team keeps looking with fresh eyes. Safety and honesty matter more than the template. Improvement follows PDCA and kaizen: small, frequent, measured experiments rather than one big process redesign.
From insight to action
A retrospective without owned actions is a complaint session. Agree on one or two experiments, assign an owner, set a check date, and carry unfinished actions into the next iteration. Reserve capacity inside the iteration for improvement work, otherwise it never happens. Track a small set of meaningful measures so you can tell whether the change helped; avoid vanity metrics. Value stream mapping exposes waste and handoffs, and systems thinking warns against local optimisation - speeding one step can starve or flood another. Evolve the Definition of Done as capability grows, and spread learning through communities of practice and mentoring (Shu-Ha-Ri).
Traps
Retrospectives that produce no actions; actions with no owner; blaming people rather than examining the system; only the Scrum Master or coach "doing improvement"; adopting a heavyweight framework wholesale when a small experiment would tell you more.
Rule of thumb: a retrospective succeeded only if at least one experiment was agreed, assigned, and reviewed next iteration.