Retrospectives: why and how to run one in a small team

Why it's the most useful meeting

Every other meeting is about what to build. This one is about how we work.

Without it a team endures the same discomforts for years: an awkward release process, perpetually unclear requirements, tasks always estimated at half their real size. Everyone thinks about it and nobody says it, because there's no moment when it's appropriate.

The retrospective is that moment.

Why it's cancelled first

Because it produces no visible output. After planning there's a plan; after a retrospective there are only agreements.

And because the first few usually go badly: people speak in generalities, nothing changes, and the conclusion "this doesn't work" appears.

It does work, but not immediately and only under certain conditions.

How to run it

Every two weeks, an hour. More often isn't needed; less often and people forget what was discussed.

Three questions:

1. What went well and should be kept.
2. What got in the way.
3. What we're changing next period.

Start with what went well. Not for positivity, but because good practices need noticing and reinforcing, or they get lost.

End with specifics. Not "we'll communicate better" but "after each task we post in the channel that it's released". An agreement that can be checked.

Take one or two changes, not ten. Nobody delivers ten agreements.

Two conditions, without which it fails

Safety. If criticising the process gets you punished, people stop speaking. The sign: everyone is silent, or says only pleasant things.

A rule helps: discuss the process, not people. Not "Peter is always slow to review" but "tasks sit in review for three days; let's agree a limit".

Following through. If nothing changed after the last retrospective, the next will be a formality. Start the meeting by checking: what did we decide last time and what did we do?

In a small team

Two or three people. Formality isn't needed, but the conversation is, around the same three questions.

Half an hour every two weeks suffices. Over tea, or on a call. What matters is that it's regular and produces at least one agreement.

In a team of two it often sounds like: "Look, let's not take three tasks at once next time, we both left things half done." That's a retrospective, just without the label.

Common mistakes

Turning it into a list of what was done. That's about output, not process.

Looking for someone to blame. The question isn't "whose fault" but "what in how we work led to this".

Discussing what you can't influence. You may complain about management decisions, but to no effect. Concentrate on what's in your hands.

Not writing it down. In two weeks nobody remembers what was agreed.

On your own project

Do it after every stage without fail. Especially the first time: everything will surface — that estimates were three times optimistic, that nobody agreed who owned what, that half the time was spent waiting for each other.

One honest review at the end of a first project teaches more about teamwork than any amount of theory.