Retrospective
Retrospective
What is a retrospective?
- The team reviews what went well, what fell short, and what to change
- Use a structured format such as KPT or 4Ls
- What makes it work: 1–3 action items, checked at the next retrospective
Once retrospectives become routine, the first thing that changes on a team is who owns the problem. Conversations that usually start with 'Who was in charge of this one?' shift in retrospectives to 'Why did no one at that stage say something looked off?' The moment a team treats problems as flaws in the structure it built rather than as individual carelessness, hidden information gets put on the table. That is why a team that has run retrospectives for a long time doesn’t see incidents disappear; it shifts toward a culture where incidents surface while they are still small.
The logistics are trickier than they look. For a sprint retrospective, a two-week cycle, 60–90 minutes, and 5–9 participants is the realistic range. Beyond ten people, someone ends up never saying a word, and from then on the retrospective hardens into a forum for the two or three loudest voices. A workable split is about 10 minutes to warm up, 20 to gather facts, 25 to dig into causes, and 20 to settle action items. Spending all the time on cause discussion and cramming action items into the last 5 minutes is the most common way retrospectives fall apart, and capping the actions you take away at three helps follow-through.
A retrospective is not the same as a results briefing or an incident root-cause analysis. A briefing plays to senior management and explains results, while an incident review aims to prevent one specific event from recurring. A sprint or project retrospective, by contrast, is for the team itself, and what it examines is not an event but the way of working itself. A team that skips the retrospective in a quarter when results were good is using this tool only for damage control. If you don’t put into words why things went well, you can’t reproduce it next time.
In practice, retrospectives usually die the moment they get tied to performance reviews. If a retrospective record passes through the team lead and is cited even once as grounds for an evaluation, every retrospective after that returns only 'nothing to report.' It is also risky for the leader to speak first. When a team lead opens with 'This time the problem was schedule management, right?', the rest of the session goes to footnoting that sentence. Making sure action items are actually handled matters more than keeping to the retrospective cadence, and when sessions pile up without follow-up, they become retrospectives for their own sake, and the team starts dodging the calendar invite with 'that meeting again.'
Seungbin JeonAn instructor who draws on psychology expertise to support communication and leadership growth in organizations
John KimInstructor John Kim, author of B2B Marketing Design and CEO of Nanum ConsultingIt originated in the post-mortem review of software engineering projects and became a regular practice as the Scrum sprint retrospective after the 2001 Agile Manifesto. Norm Kerth established it as a methodology in his book Project Retrospectives, setting out the retrospective's core norm, the Prime Directive: 'everyone did the best they could.'
Consider a hypothetical case: the marketing division of Company A, a household appliance maker with 210 employees. A spring new-product launch campaign that spent KRW 300 million (≈ US$224,500) over six weeks stalled at 68% of its sales target, and the media run date was changed twice after the ad creative swap slipped three times. The division head instructed, 'No cause report. Have the team reflect on it themselves,' and a KPT retrospective was held for the first time.
- Three days after the campaign ended, they blocked out 90 minutes, and the marketing team lead spoke first. 'Holding creative approvals at my desk for two days was a big part of it,' the lead said. Only then did the people doing the work start to speak up.
- Eight team members spent seven minutes anonymously writing Keep, Problem, and Try items on sticky notes, and 62 notes went up. Mixed in were lines that would never have come out in a verbal discussion, such as 'Nobody reads the weekly agency report.'
- The brand manager serving as facilitator rewrote 'The design team was late' as 'The media run date was set before the creative was finalized,' and the blame game shifted to a schedule-design problem.
- Using dot voting with three votes per person, they kept just two Tries. 'Lock creative approval at D-10' and '15-minute weekly media-design sync' each got an owner and a next check date, and were posted at the top of the team wiki.
- In the next-quarter campaign, creative swap delays dropped from 3 to 0, the KRW 4.2 million (≈ US$3,140) media change fee was never incurred, and preparation time shrank from six weeks to five. From the third retrospective on, the action-item completion rate exceeded 80%.