Every method that iterates builds in a moment to look at the method itself. In Scrum it is the sprint retrospective, the last event of each sprint, in which the team asks what went well, what did not, and what to change. The subject is the team's own working: its tools, its communication, its definition of done, its interactions with the people around it, and not the product, which the review covers. The output is improvement, and the guide is specific that the most impactful improvements are addressed quickly and may be added to the next sprint's backlog, which is what turns a discussion into a commitment.
- Set the stage: what period, what question, and the reminder that the point is the system, not the individuals.
- Gather data: what actually happened, from everyone, before anyone interprets it. Timelines, counts, the moments that felt wrong.
- Generate insights: why those things happened, which is the step most retrospectives skip on the way to blaming.
- Decide what to do: one or two changes, specific, owned, small enough to be done before the next retrospective.
- Close: check that the changes from the last retrospective were made, and whether they worked.
The meeting fails in predictable ways. It becomes a ritual with the same three columns and the same observations, and produces nothing. It becomes a search for who is at fault, and people stop saying what they saw. It produces ten actions, none of which is done, and the next one produces the same ten. The corrective for all three is the same: vary the format so the conversation is fresh, hold the line that the subject is the system rather than the person, and leave with one or two changes that will visibly exist next time. A team that has made one real improvement a sprint for a year has changed beyond recognition.