A retrospective is a regular, timeboxed inspection of how the work is being done, held by the individuals doing it and ending in a change which they will make. It is the mechanism by which a team improves at its own process and not merely at its subject.
Frequency is where the value lies. Where a team examines its working every two weeks, it makes twenty six small corrections in a year, each of them on evidence still fresh enough to be accurate. Doing so once at the end produces a document for a project that has already finished.
Why the output has to be a change
The failure mode is a session which generates a list. Things that went well, things that did not, all of it filed, and then the same list appears at the following session.
What prevents this is a limit on the output. One change, occasionally two, specific enough that anybody can tell afterwards whether it happened, and with a name against it. Where a team attempts six improvements at once it will implement none of them, and the experience teaches everybody that retrospectives do not work.
Each following session then opens by checking the last change. Did it happen, did it help, and should it stay. That single habit turns a series of meetings into a process, because it makes the previous session's decision consequential.
A structure that reliably works
| Stage | Purpose | What it prevents |
|---|---|---|
| Set the stage | Get everybody speaking early and agree what the session covers | A session where two people talk and the rest observe |
| Gather data | Establish what actually happened, with facts before opinions | An argument between competing recollections |
| Generate insight | Ask why the data looks like that, and look for causes rather than events | Fixing a symptom that recurs in a different form |
| Decide what to do | Choose the change, name the owner, agree how it will be visible | A list of good intentions |
| Close | Confirm the decision and check how the session itself went | The same unproductive format repeating for months |
Gathering data before generating insight is the stage most often skipped and the one which does most of the work. Begin from opinions and the session will debate opinions. Establish first what happened, when, and what the measures showed, and the team generally discovers that the disagreement was about facts. Facts are checkable.
Making it safe enough to be useful
A retrospective surfaces the real problems only where individuals are able to name them without cost. Where a manager who conducts appraisals is in the room, or where a previous session led to someone being blamed, the team will discuss tooling and avoid the working relationship which is the actual constraint.
Two practical measures help. First, keep the session to the team, and escalate whatever needs escalating as a separate act afterwards and not in front of an audience. Secondly, treat every account as an honest attempt given what that individual knew at the time. This turns the question from who did this into what made this the reasonable thing to do.
Root cause, and knowing when to stop
Asking why repeatedly moves the discussion from an event to a cause. A missed date becomes a late dependency, which becomes a request raised too late, which in turn becomes a planning conversation which does not include the team supplying the work.
Stopping should occur at the last cause the team is able to do something about. Continuing past that point produces a conclusion about organisational structure which is probably true and entirely unactionable, and a session which ends there has taught the team that the problem lies beyond them.
Continuous improvement beyond the team
Retrospectives improve one team. Improvement across an organisation requires the findings to travel, and this is where most of the value is lost.
What travels is a repository which someone actually searches, and it is worth being honest that most repositories are not searched. Such a repository earns its keep on two conditions. The entries must be written for a reader and not for a filing requirement, which means the situation, what was tried, what happened and what to do differently. Someone must also be responsible for surfacing relevant entries at the start of new work, and not simply waiting for a search.
There is also a structural route. Where three teams independently identify the same blocker, the fix belongs to whoever owns the thing which blocks them, and carrying that pattern upward is a project manager's job and not a team's.
Where each syllabus puts it
Scrum requires a retrospective at the end of every Sprint, timeboxed and attended by the whole team, and requires that at least one improvement be added to the following Sprint's work. Lean approaches treat the same activity as kaizen, which is a standing expectation of small continuous change and not a scheduled event. Predictive practice has historically placed the equivalent at phase gates and at closure.
PMI expects continuous improvement throughout and not only at the end. Exam questions generally test the distinction between a review and a retrospective, who belongs in the room, and whether the candidate treats an improvement as something owned or merely as something noted.