Scrum asks developers to self-organise. In nearly every business I have seen adopt it, the organisation around those developers does not.

The team runs sprints. Around it sit annual budgets, fixed launch dates, procurement cycles, an architecture board that meets once a month and a sales team that has already promised the feature. The inputs are fixed and dated. The outputs are fixed and dated. The team is agile in the middle. An agile island in a waterfall ocean.

That gap, between the authority a team is told it has and the authority it actually has, causes more trouble than most process debates.

Where the ambiguity actually bites

In my last post on team shape I argued that a user story was never meant to be the spec. It is a placeholder for a conversation, and the detail is supposed to be settled in that conversation with someone who can make the call.

The trouble is that in the island model, nobody outside the team is empowered to answer the questions the story raises. The product owner can speak for priority but not for the budget. The architecture board can speak for standards but not until next month. So the team answers the questions itself.

Who fills the vacuum

Usually the most senior or most confident developer. Someone has to decide, and they are the obvious candidate.

I have written before about the hero developer, and this looks similar, but it is a different failure. The hero problem is about knowledge concentrated in one head. This is about decision authority concentrated in one voice. Often the same person, but the fixes are different. Rotation and documentation spread knowledge. They do nothing about who gets the final word.

Put four to six developers in a room, each with sound instincts and different opinions, and you get one of two outcomes. Either the loudest voice wins, or the team settles on a consensus that nobody quite believes in. Neither is a decision in any meaningful sense.

What Scrum says about bad decisions

This is the honest gap in the framework. Scrum divides authority cleanly:

  • The product owner owns what gets built and in what order.
  • The developers own how it gets built.
  • The Scrum Master owns the process and chairs the conversation.

Notice what is missing. The Scrum Master arbitrates process, not content. They have no standing to overrule a poor technical decision, and the framework deliberately gives them none. The product owner can reject an increment, but not an architectural choice buried inside it.

Scrum assumes the sprint review will catch problems. The review looks at increments and outcomes. It does not look at the database the team chose, the service boundary they drew or the dependency they took on. By the time those choices show up as outcomes, they are in production and expensive to reverse. I wrote about how early decisions compound, and this is exactly the kind that do.

Self-organising into the wrong shape

So what happens when a team self-organises into something that suits the team and hurts the company?

It is rarely dramatic. It looks like a team picking the technology it wants to learn rather than the one the organisation can support. Or a service boundary drawn around who is working on what, rather than around the domain. Or the unglamorous migration that keeps sliding to next sprint because nobody on the team wants it.

Each choice is locally rational. None is malicious. The team is responding to its own incentives, and nobody with a view of the whole has the standing to step in.

Put the boundary outside the team

My view is that governance for decisions that outlive a sprint has to sit outside the team. Scrum purists will not like that. The alternative is hoping the team's incentives happen to line up with the business's, and hope is not a control.

That does not mean returning to an architect in an ivory tower handing down diagrams. What has worked for me is lighter:

Explicit decision rights. A short, written agreement of what the team decides alone, what it decides and tells someone about, and what needs sign-off. Most decisions fall in the first bucket. The few that do not are the ones that compound.

Architecture decision records with a named owner. Cross-cutting decisions are written down, with the options considered and the reason for the choice, and a named person outside the team who holds the deciding vote. Authority without the apparatus.

A small, frequent forum. Thirty minutes a week beats a monthly board. A decision that waits four weeks for approval is a decision the team will make without you.

Someone who holds coherence. The role I described as missing from the archetypes model: the person who decides what not to build and makes sure several fast-moving people are building one system rather than several.

Why not SAFe?

SAFe does reintroduce these roles. Architects, release train engineers, portfolio management. I give it credit for being honest that enterprises need them.

My reservation is that it tends to recover governance by adding ceremony. It can end up formalising the waterfall ocean rather than fixing it, with increments that behave like phases and planning events that behave like stage gates. For many organisations, clear decision rights and a named owner deliver most of the benefit at a fraction of the weight.

AI makes this more urgent

With AI doing more of the implementation, the ambiguity in a user story no longer gets resolved in a conversation. It gets resolved silently by an agent, or written into a specification by whichever developer prepares the prompt. A specification carries authority that a conversation does not. It is harder to argue with a document than with a colleague.

So whoever writes the spec is now making the decision. That is fine, as long as someone has decided who that should be and where the boundary sits.

Empowerment needs enablement

Telling a team it is empowered while every decision about money, scope and dates is made somewhere else is not empowerment. It is responsibility without authority.

There are two honest options. Extend real authority beyond the team, into how scope and funding are set. Or be explicit about where the team's authority ends and who picks up from there. A team that knows where its boundary is will decide faster and better than one that has been told it has no boundary at all.

If you are working out where that line should sit in your organisation, I am happy to compare notes. No pitch, just a conversation if it is useful.