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.