Project operations·6 min read
How to run a team retrospective people will actually use
A retrospective is useful when it changes the next cycle of work. It does not need to produce a perfect account of the past or a long list of complaints.
Collect observations before debating causes
Ask what helped, what created friction and what surprised the team. Keep early input factual and specific: an unclear handoff, a late decision, a useful template or a dependency that changed.
Separating observations from conclusions gives quieter participants a chance to contribute before the most confident explanation takes over.
Choose one or two changes
A retrospective with ten actions changes nothing. Choose the smallest changes that have a clear owner and can be tested in the next project or sprint.
Write the action so that another person can tell whether it happened. ‘Communicate better’ is an aspiration; ‘add a decision owner to every project brief’ is a practice.
- One owner per action.
- A moment to test it.
- A visible definition of done.
Close the loop next time
Begin the next retrospective by checking the previous actions. This creates accountability without turning the meeting into blame, and shows that feedback has a real effect on how the team works.