Retrospective

Plenty of teams hit the same problem every cycle. The last day runs late into the night on a deploy, requirements shift mid-cycle and half the work gets rebuilt, code review arrives a day late and something that could have shipped rolls over.

Individually, everyone knows what is wrong. What is missing is a place to say it. Raise it mid-cycle and it reads as postponing something urgent; raise it privately and it reads as an accusation about a specific person. So nobody says anything and the next cycle produces the same evening.

At Pagedeck, three cycles in a row ended with a deploy running until eleven at night. All five people knew it, and it had never once come up in a meeting, because the deploys themselves had all succeeded.

The retrospective fills that gap by being a standing calendar entry. The meeting for looking at what got built exists separately, so this one handles only how it got built. Being regular is the point. It opens on a scheduled day rather than when something goes wrong, which means nobody has to decide that a problem is large enough to justify calling a meeting, and nobody has to save up grievances waiting for an opening.

Open the room, gather observations, sort them, and close by settling one or two changes with an owner and a date. Six steps.

1. State the scope first. The facilitator says in one sentence that this examines methods rather than people. Without that line, by about the third retrospective the meeting becomes an audit of who was late with what, and attendance falls off from there.
2. Everybody writes silently. Five to ten minutes, no talking. Start with discussion and the conversation tilts toward whatever the first speaker raised, and the person holding a different view loses what they were going to write.
3. Sort into a format. Keep-Problem-Try uses three columns for what to keep, what is wrong, and what to try. Start-Stop-Continue splits into what to begin, what to end, and what to carry on. Liked-Learned-Lacked-Longed for uses four. Repeating one format gets stale, so many teams rotate two or three.
4. Narrow it down. About twenty items end up on the board, which is more than can be discussed. Give everyone two votes and talk about the two or three that collect the most. The items that lose are not thrown away; they usually reappear if they were real.
5. Convert to action items. An owner and a date are what make something an action item. "Communicate better" causes nothing to happen next cycle. "Deploy two days before the last day, and Theo writes up the procedure by Friday" is an action item.
6. Review last cycle's actions in the first five minutes of the next retrospective. Skip this step and what gets decided does not get done, and once that repeats, the meeting is a formality.

Everybody who worked the cycle attends: engineers, designers and the product manager together, usually five to ten people. Above ten, some people stop speaking, and splitting into two groups works better.

Some people are better off not attending. With a manager who holds evaluation authority in the room, the range of what can be raised narrows. Sharing only the conclusions afterward usually works better.

One person facilitates. Where there is a scrum master, they do it; otherwise it rotates. The facilitator keeps time and stops one person from dominating, rather than contributing opinions of their own, which is why rotating the role stops it becoming one person's meeting.

The timing is the last day of the cycle, directly after the sprint review has shown what got built. Memory is still fresh, and whatever gets decided applies starting with the next cycle. For a two-week cycle, 60 to 90 minutes is the usual allocation.

Some sessions sit outside the cycle. An incident gets its own postmortem, and a project running several months gets a longer-range session covering more than one cycle at a time.

"Let's spend this whole retro on deploy timing. It's the same problem three cycles running."

Concentrating the time on one recurring issue.

"That's not an action item. There's no owner and no date on it."

Pointing out that a decision will not turn into anything.

"Can we start with last retro's actions? One of the two didn't happen."

Actually performing the step that checks the previous cycle's decisions.

At Pagedeck, Mia facilitates, and 90 minutes gets blocked on the afternoon of the last day, after the review. The team alternates between two formats, and items go up on the board only after everyone has written silently, which keeps the loudest voice from setting the agenda.

The late-night deploys came up for the first time in this meeting. Theo wrote down that it had been three cycles of working late, and it collected the most votes. The action item was moving the deploy from the last day of the cycle to two days earlier, with Theo writing up the procedure. Checking in the first five minutes of the following retrospective, the item was done, and the last-day late nights stopped, which is the kind of result that makes the next retrospective easy to fill.

The most common misreading is that this is a meeting for taking turns saying what went well and what did not. The format looks like that and most of the clock is spent talking, which invites the conclusion. But the output is not the conversation; it is one or two things that change next cycle. Airing frustration has value of its own, yet a meeting that ends there is one nobody wants to attend four months later, because the same things get said and nothing moves. If the notes contain no line with an owner and a date, the retrospective may as well not have happened.

The second misreading is that it can be skipped when nothing is wrong. It is the first thing deleted from a busy cycle. But recurring problems are produced by being busy. A deadline forces a step to be skipped, the next cycle gets busier as a result, and so the retrospective gets skipped again. Missing it once makes missing it twice easy, and a team that has missed three in a row usually does not restart. When time is genuinely short, cutting 90 minutes to 30 and handling one item beats cancelling.