Retrospective

A retrospective is a recurring session in which a team examines how it has been working and decides what to change. It is distinguished from a review, which inspects the product, by focusing on the process, the collaboration, and the conditions the team operates under. It is the mechanism by which a team improves itself rather than waiting to be improved.

Its structure is conventionally simple: establish what happened, gather observations about what helped and what hindered, identify the most significant themes, and agree specific changes to attempt. The variations in facilitation format are numerous and largely interchangeable; what determines value is not the format but whether the session produces changes that are actually made.

The most common failure is the absence of follow-through. Teams identify the same impediments repeatedly, record actions, and never complete them, at which point the session teaches everyone that raising problems achieves nothing. Attendance becomes obligatory rather than useful, and contributions become perfunctory. Tracking a small number of agreed actions as visible work, with owners, and reviewing their completion at the start of the next session is the single change that most reliably rescues the practice.

Selecting too many actions is the related failure. A session generating fifteen improvements produces none, because the team's capacity for change is limited and diffuse effort achieves nothing observable. Choosing one or two changes, implementing them properly, and assessing whether they helped produces compounding improvement, and the discipline of choosing implies declining most of what was raised, which requires explicit prioritization.

Psychological safety determines whether the session surfaces anything real. If people believe that identifying a problem will be treated as blame, or that criticizing a decision will have consequences, the observations offered will be safe and superficial. The presence of line managers, the handling of the first genuinely uncomfortable topic raised, and whether previously raised issues were acted on all shape what people are willing to say.

Scope frequently needs to extend beyond the team's own control, which is where retrospectives become organizationally useful and politically difficult. Many of the most significant impediments originate outside the team, in dependencies, approval processes, unstable priorities, or resourcing. A team that only discusses what it can change alone will exhaust the available improvements quickly, whereas escalating well-evidenced external impediments is frequently where the largest gains sit.

Facilitation deserves more attention than it usually receives, particularly regarding who runs the session. When the person facilitating is also the person whose decisions are most likely to be questioned, the range of what gets raised narrows considerably. Rotating facilitation, or occasionally bringing in someone outside the team, changes the dynamic enough to surface topics that had been avoided.

Cadence and depth should vary rather than being uniform. A short session each iteration maintains the habit and catches immediate issues, while a longer periodic session examining patterns over several months surfaces structural problems that are invisible at fortnightly resolution. Teams running only the short version tend to address symptoms repeatedly without noticing the recurring cause.

Because many identified impediments require decisions the team cannot make, the practice only produces its full value where the surrounding organization is prepared to act on what emerges. In practice retrospectives are established within product development as part of the delivery rhythm, and where the recurring impediments are structural rather than local they become an input to the operating model work handled through strategic planning and consulting.