Management Frameworks & Methodologies

Retrospective

A dedicated meeting held at the end of a project or time-boxed period (sprint) to reflect on what went well, what went wrong, and how to improve future processes.

What is a Retrospective?

A retrospective (often called a “retro”) is a ritual borrowed from Agile methodology. It is a recurring meeting where a team looks back at their recent work to discuss their processes. Typical frameworks ask questions like: “What should we start doing?”, “What should we stop doing?”, and “What should we continue doing?” Unlike a post-mortem, which usually happens only after a massive failure or the end of a major project, retrospectives are regular (e.g., bi-weekly), focusing on continuous, incremental improvement.

Why Retrospectives Matter for Managers

Continuous improvement is impossible if a team never pauses to reflect on how they are working. Managers use retrospectives to uncover hidden bottlenecks, address simmering frustrations before they turn into major conflicts, and celebrate unsung wins. Importantly, a good retrospective separates the what from the who, focusing on systemic process issues rather than blaming individuals. If a team feels they are constantly running on a treadmill and repeating the same mistakes, a well-facilitated retro is the manager’s best tool for breaking the cycle and giving the team agency over their own workflow.

Real-world Example or Application

After a two-week development sprint, the engineering manager facilitates a retrospective using a digital whiteboard. The team anonymously adds sticky notes to columns labeled “Mad,” “Sad,” and “Glad.” A cluster of notes under “Mad” reveals that developers were blocked waiting for design assets. Instead of blaming the designers, the manager guides the team to a systemic solution: they agree to implement a new “Design Definition of Done” checklist before any engineering ticket can be pulled into a sprint. The process improves immediately in the next cycle.