The worst retrospectives I’ve sat through all had the same shape: we missed the sprint goal, so the whole hour turned into an inquest about the goal. The best ones barely mentioned the goal at all. We talked about how we’d worked, what got in the way, and what we’d try differently next time. That difference is what people mean by an outcome-independent mindset, and having run sprints myself for a while now, I think it’s the most useful attitude a Scrum Master can hold.

To be clear: results matter. Nobody pays us to have a lovely process and ship nothing. But delivering the sprint is the team’s job. The Scrum Master’s job is to improve the machine that delivers sprints. Those are different jobs, and mixing them up causes most of the dysfunction I’ve seen around Scrum.

Scrum Master vs project manager

#

The two roles get confused all the time, partly because plenty of companies hand both to the same person. The core difference:

Scrum itself has no project manager role. Much of what a project manager would usually do is split between the Product Owner, who decides what gets built and in what order, and the Developers, who plan how to build it.

What changes when you let go of the outcome

#

The team gets room to actually own things. Scrum is supposedly built on self-organising teams, but a Scrum Master who sweats every result ends up steering decisions, and the team quickly learns that decisions aren’t really theirs. Focus on process instead and you can let people experiment, make the occasional wrong call, and learn from it — which is the only way real ownership ever develops.

Retrospectives get honest. When the question in the room is “why did we miss the number?”, the true answers go into hiding. When it’s “what slowed us down, and what do we try next?”, people talk. The same goes for impediments mid-sprint: an outcome-obsessed Scrum Master panics about the deadline, while a process-focused one just gets on with removing the blocker, or suggests a time-boxed spike when the blocker is something nobody knows enough about yet.

Stakeholders calm down too. If the only story you can tell is the burndown chart, every wobble looks like failure. If you can also talk about what the team learned and how it’s adapting, expectations become more realistic — and the team gets shielded from a lot of pressure that would otherwise land on them halfway through a sprint.

If you’re already fixated on a result

#

Easier said than done, I know. When you’re deeply invested in something turning out a particular way, “just focus on the process” sounds like a fridge magnet.

A few things that actually help. First, don’t beat yourself up for caring — wanting a result is normal, and pretending otherwise doesn’t work. Second, translate the outcome goal into process goals you control: not “win the competition” but “practise 30 minutes a day”. You can’t control whether the release lands well; you can control whether it was reviewed, tested, and demoed early. Third, notice what’s feeding the fixation. If you’re refreshing a dashboard or a stock price ten times a day, pick set times to check and stop otherwise. And celebrate the small wins along the way, because the distant goal will happily eat all your attention if you let it. If the fixation is genuinely wrecking your sleep or your daily life, that’s worth talking to a professional about — no shame in it.

Results still matter. But the teams I’ve seen get them consistently are the ones where somebody is looking after the how, not just the what.

The meeting is the easy part

#

The structure is almost embarrassingly simple. After a sprint or a project phase, the team sits down and works through three questions:

1. What went well?
2. What didn’t go well?
3. What can we improve?

That’s it. The point is the feedback loop: pause regularly, look at what actually happened, and feed it back into how you work. A team that never pauses just repeats itself.

What separates useful retros from venting sessions

#

Candour, mostly. People will only name the real problem if they’re confident it won’t be held against them, so the safety of the room matters more than whichever format you picked. And the sharpest observations usually come from the quiet people — a retro where only the lead talks is a status meeting with extra steps.

The other half is what happens after the discussion. Every issue worth fixing should leave the room as an action item with a name and a deadline attached. Then — and this is the part most teams skip — open the next retro by reviewing last time’s items. Nothing kills retros faster than everyone quietly realising the action items are decorative.

Where you can, bring numbers too. Opinions like “the sprint felt slow” go in circles; a chart usually settles it.

The failure modes

#

Three I’ve seen up close: retros that turn into blame (fix the system, not the person), retros that run the identical format for a year until everyone’s on autopilot (change it up), and retros with no follow-up at all — which, as above, is the fatal one.

None of this is specific to software, by the way. Marketing campaigns, event management, research projects, manufacturing — anything with a repeating cycle benefits from the same loop. But wherever you run them, the test is the same: did anything actually change before the next one? If not, you’ve just been talking.