High-level chess players sit down after every game, even one they won, and take it apart. Move by move. Where there was a strong move, where a weak one, where the opponent could have punished them and did not, where they themselves missed a better continuation. This analysis sometimes takes longer than the game itself. An amateur celebrates a win, gets angry after a loss and goes off to play the next game. A professional learns from every one. A year later the difference in level is enormous.
Most companies play like amateurs. A project ends, everyone exhales, someone gets a bonus, someone gets a reprimand, and straight on to the next project. Mistakes that cost weeks and money are forgotten within a month. Six months later they are repeated in a new project, and everyone is sincerely surprised: how did this happen again?
A retrospective is not a search for the guilty
Let me state the main point right away, because this is where most attempts stumble. A retrospective analysis is not a dressing-down in the military sense, where the goal is to find someone to punish. As soon as a review turns into a hunt for the guilty, people start defending themselves, hiding mistakes and shifting responsibility. And the analysis loses its point, because the most valuable information, about what really went wrong, remains unsaid.
Civil aviation understood this long ago. Accident investigation is built on the principle that the goal is to understand what happened, not to punish. Pilots report their mistakes and dangerous situations because they know the reports will be used to improve the system. That is why aviation became one of the safest modes of transport. Not because pilots do not make mistakes, but because every mistake becomes a lesson for everyone.
If a retrospective looks for someone to blame, next time the mistake will simply be hidden. Ask not who, but why.
Three questions where it all starts
You can invent elaborate formats with cards and coloured sticky notes, and sometimes they help. But the essence of any retrospective comes down to three questions.
- What went well and needs to be reinforced? Successes are analysed less often than failures, and that is a mistake. If You do not understand why something worked, it will not happen again next time.
- Where did we lose time, money or nerves? Specifically: at which stage, because of what, how much.
- What exactly will we change in the next cycle? Not "we'll be more careful", but a concrete action with a concrete owner.
The third question is the most important and the one most often failed. A retrospective without changes is just a joint complaint about life. It feels good to vent, but nothing changes. The rule I use: a retrospective should produce one to three changes, no more. Each has an owner and a deadline. At the next retrospective the first thing we check is whether they were done.
How to run it so it is worth it
A few things from practice that greatly increase the value.
Start with facts, not opinions. Reconstruct the timeline: what happened and when. What the agreements were, when requirements changed, when the problem was discovered. It is amazing how differently participants remember the same project. A timeline aligns the picture and removes "but I thought that..." arguments.
Dig to the root. A missed deadline is a symptom, not a cause. Why was it missed? Because we got the data from the client late. Why late? Because we did not agree who would request it. Why did we not agree? Because at the start there was no list of dependencies. Now that is a cause, and it can be fixed at the process level. The "five whys" method sounds naive, but it works.
The leader speaks last. If the boss speaks first, everyone else will adjust to his opinion. Let those who did the hands-on work speak first.
Write it down. The results of a retrospective must go into the company's knowledge base, otherwise a year later a new person will step on the same rake because he did not know it was there.
Not only for projects
Retrospectives are usually associated with development teams and Scrum, where they happen every two weeks. But the same approach works at the level of the whole company. Once a quarter, gather the key people and take an honest look: what worked, what did not, which decisions turned out right and which did not. Which clients brought profit and which only trouble. Which processes help and which have become bureaucracy. This does not replace strategic planning, but it makes it much more accurate, because planning without analysing the past is built on the same illusions as the previous plan.
At Ingello we run a review after every client project and after every major internal experiment. Many of our current working rules, from how we estimate projects to how we package prototypes, grew out of exactly such reviews. Every rule is a rake someone once stepped on.
What to do tomorrow
Take your last completed project or stage. Gather the people who took part in it for an hour. Start with the timeline, then the three questions: what to reinforce, where we lost, what we change. Forbid looking for the guilty and speak last yourself. Write down no more than three changes with owners and dates. A month later check what has been done. If even one change has really been implemented, You are no longer playing like an amateur.
