Working method / collaboration and strategy

A retrospective is a business tool, not only a Scrum event.

Safe space: make room for every voice, including the quiet and hesitant. Turn individual concerns into shared patterns, and give leaders a clearer view of where action matters most.

I have worked with Agile ways of working and Scrum. The practice I have carried with me is the retrospective. Its value extends well beyond a sprint or a software team. Used well, it can help almost any group, at any level of an organisation, understand what is working, surface what is getting in the way and decide what to improve next.

Retrospectives must always be a safe space for everyone. They should also be enjoyable.

They are particularly useful when people do not normally work closely together, or do not feel their views reach the wider discussion. A retrospective gives those people a shared structure for contributing their experience, seeing how it connects with others and deciding what to do next.

A route into the wider discussion

Someone should not have to carry a concern into the wider conversation alone.

Sometimes someone has a useful idea or sees a problem clearly, but does not feel their view is important enough to raise with leadership. They may also not have a comfortable or obvious way to do it.

The retrospective helps break that barrier. Everyone starts with the same chance to contribute. The group then shares and groups the ideas, so an individual does not have to carry a concern alone. When others recognise the same problem, the discussion has a stronger foundation and leadership can hear the pattern as well as the individual view.

What happens when people share the room

A personal frustration becomes a recognised pattern.

People often arrive thinking that a concern or idea is unique to them. Once everyone contributes and the themes are grouped, they can see where the experience is shared.

That changes the conversation. A good idea finds other people who can develop it. A group that normally works in isolation begins to see the wider system it is part of.

Real exampleOctober 2025 infrastructure retrospective

A cross-functional infrastructure summit

Start with the people closest to the work.

I organised a four-day IT infrastructure summit that brought together people from normally separate operational, security, network, services and engineering functions.

We began with a retrospective. When the notes were shared and grouped, the room identified 11 common themes, including integration, alignment, governance, resources, autonomy, documentation and visibility.

Those themes gave the rest of the summit a shared starting point. They informed collaborative work on service ownership, documentation and cross-team technical priorities. For each theme, we separated what the teams could do from what they needed from leadership.

That also gave leadership a clearer view of the work: what teams were experiencing, where the dependencies sat and which actions would make the greatest difference.

Link to this example

The session

Enough structure to turn the conversation into useful action.

Open the room

Start with a light prompt. Everyone speaks early, before the conversation becomes formal.

Gather the views

People work alone or in small groups on what went well and what could be better.

Find the themes

Share the notes, group the patterns and make the common experience visible.

Choose what matters

Consider impact and effort, then select the improvements the group can actually take forward.

Follow through

Agree the output, what can be shared and how actions enter normal work tracking.

A reusable session plan

Make the follow-up visible.

OpeningEveryone has spoken once.
ReflectionIndividual or small-group notes.
ThemesA shared view of the main patterns.
DecisionsA short list of practical actions.
CloseAgreed communication and follow-up.

I would not use a retrospective to allocate blame, revisit every decision or create a long list of actions that nobody has capacity to take on. The value comes from listening well, choosing a manageable number of improvements and returning to them later.

Explore more working methods ←