A project ends, the client is happy enough, and the team is already busy with the next one. Nobody asks why the delivery slipped by two weeks, why the same question about scope came up three times, or why one person did most of the evenings. A few months later the next project has the same problems.
A retrospective is the simplest fix: a short, structured conversation after the work is done. It does not need a facilitator, a tool or a workshop. This article describes a thirty-minute version for teams of roughly five to fifty people, and a way to make sure it changes something.
When and who
Hold it within a week of finishing, while people still remember the details. Waiting a month turns it into a vague talk about how things felt.
Invite the people who did the work, plus the person who dealt with the client if that is someone else. Keep the group to eight or fewer. A manager can attend, but should speak last; people say less when the person who sets priorities talks first.
Pick one person to keep time and write notes. It can be anyone, and it helps to rotate the role. It should not be the person who led the project, because that person also has things to say.
Prepare in ten minutes
The meeting is short, so the preparation matters. Before the meeting, the note-taker collects a few facts on one page:
- the original plan: scope, date, who was involved;
- what was delivered and when;
- the changes along the way, such as new requests, delays and people joining or leaving;
- any messages or decisions that people will want to refer to.
If you keep a decision log, take the entries from there. Our article on a one-page decision log shows a format that makes this step quick.
The agenda
| Minutes | Step | Question |
|---|---|---|
| 5 | Facts | What happened? Walk through the one-page timeline; correct anything that is wrong. |
| 8 | What worked | What should we do again on the next project? |
| 8 | What did not | Where did we lose time, quality or patience? |
| 9 | Decisions | Which three changes would help most? Who owns each one, and by when? |
Keep to the times. If a topic needs more, write it down as a separate follow-up instead of letting it eat the decisions step.
Facts first
Starting with facts prevents the common argument about whose memory is right. Read the timeline aloud and let people add what is missing. Do not judge yet.
What worked
This step is easy to skip and should not be. A team that only discusses problems begins to dislike the meeting. Ask for concrete things: the kickoff checklist that avoided a misunderstanding, the short weekly note that kept the client calm, the person who checked the work before it went out. Things that worked are the ones you want to protect when the team gets busy.
What did not
Ask about the process, not about people. "The client's feedback arrived in three different channels" is useful. "Alex forgot to forward it" is not, and it stops people from speaking honestly the next time. If a topic really is about one person's performance, it belongs in a private conversation, not in this meeting.
Good prompts are:
- Where did we wait for something or someone?
- Which decision did we make twice?
- Where did work have to be redone, and why?
- What did we learn only at the end that we should have known at the start?
Decisions: three changes at most
The meeting is only worth the time if something changes. Pick no more than three changes. More than that, and none will happen. For each change write one sentence that says what will be different, one name for the owner and one date.
A weak change: "Improve communication with the client." A usable change: "Send the client a five-line status note every Friday; Maria owns it; starts next week." If the team already uses a short written update, our article on a Friday status note can serve as a template.
Keep the notes short
One page is enough: the timeline, two or three lines under each of "worked" and "did not", and the three changes. Store it where the next project team will look, for example next to the project folder or the checklist you use at kickoff. A retrospective that nobody can find later is only a pleasant conversation.
Close the loop
Begin the next retrospective by reading the previous three changes and asking one question for each: did it happen? If not, why not? Sometimes the answer is that the change was too big or the owner was moved to other work. That is useful information, and it is better to drop a change openly than to let it fade.
Common mistakes
- Waiting too long. After a month, people remember only the last few days.
- Turning it into a blame session. Talk about steps and handovers, not about individuals.
- Too many actions. Ten ideas become zero changes.
- No owner or date. "We should" is not a decision.
- Never checking back. If changes are not reviewed, people stop proposing them.
A first step
After your next project ends, put thirty minutes in the calendar within the week. Ask one person to prepare the one-page timeline and take notes. Use the four steps above, finish with three changes and write the date when you will check them.
Sources
- Agile Manifesto, Principles behind the Agile Manifesto (principle 12: the team reflects at regular intervals and adjusts)
- The Scrum Guide, section on the Sprint Retrospective
- Google Site Reliability Engineering, Postmortem Culture: Learning from Failure (blameless review)
- This article is a planning aid. The examples are generic and the names are invented. No client results or performance figures are claimed.