Almost everyone works in something called Agile and almost nobody can say what it is supposed to achieve. That gap is why the practices get performed rather than used, and why “we're Agile” is compatible with a two-year release cycle.

The manifesto is four preferences, each of the form A over B — and the phrasing matters, because it says explicitly that there is value in both. It prefers individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; and responding to change over following a plan.

The underlying claim is about feedback latency. Building software involves learning what you should have built, and you learn it fastest by putting something in front of someone. Everything else — short iterations, working software, collaboration — follows from wanting that loop to be short.

So the diagnostic question for any practice is: does this shorten the loop between building something and finding out whether it was right? A daily stand-up where people report status to a manager does not. A demo to a real user does.

The most common structural mistake in delivery is running Scrum in a team whose work arrives unplanned. A platform or support team cannot commit to a two-week scope when half its work will be discovered on Tuesday, so the sprint is broken every sprint, the commitment becomes meaningless, and everyone concludes the process does not work. The process is fine; it is the wrong process for that work.

Estimation generates more argument than any other practice and the honest position is narrower than either camp's.

• Story points were invented to avoid arguing about hours, by expressing relative size instead. The moment anyone converts points to hours or compares velocity across teams, the mechanism is defeated and you are arguing about hours again with extra steps.
• Velocity is a planning aid for one team, not a productivity metric. Using it to compare teams or to set targets guarantees inflation, immediately and permanently, because the number is defined by the people it measures.
• Counting items works about as well as estimating them. There is reasonable evidence that forecasting from the historical distribution of how long items took beats forecasting from estimates — because items cluster in size more than people expect, and estimates are systematically optimistic in ways history is not.
• So the defensible practice is to break work down until items are roughly similar in size, count them, and forecast from your own historical cycle-time distribution — giving a range with a confidence rather than a date. ‘Eighty-five percent of items like this finished within three weeks’ is both more honest and more useful than a point estimate.
• And the breakdown itself is where the value is. Most of the benefit people attribute to estimation comes from the conversation that reveals nobody had thought about migration, or auth, or the third-party rate limit. Keep the conversation; the number is a by-product.

Frameworks for coordinating many teams exist because the coordination problem is genuine: twelve teams working on one product do have dependencies, and something has to resolve them.

The honest assessment is two-sided. The critique is fair — the heavier frameworks reintroduce most of the planning apparatus the original ideas were reacting against, and a quarterly planning event that fixes scope for three months is a waterfall with ceremonies. And the problem they address is real, so “just don't scale” is not advice.

The version that works, in my experience of what survives: reduce the coordination need rather than manage it better. Teams organised around a product area with the skills to ship independently have few dependencies to coordinate; teams organised around a layer of the stack have one for every feature. That is a structural fix, and it makes the framework question much less important — which is why the most useful thing a delivery leader can do is usually an org-design change rather than a process change.

The most-copied organisational design in software was never fully implemented at the company it is named after, and the people who wrote it down have said so publicly.

The cross-functional team worked. What failed was the matrix management of engineers, and the mechanism is specific enough to be useful:

• Chapter leads managed engineers by specialism across teams and had little responsibility beyond career development of the people they managed.
• So the product manager had no equivalent peer — no counterpart with delivery accountability who could negotiate priorities at the same level. There was no single person accountable for the engineering team's delivery.
• The escalation arithmetic: a team with backend, web and mobile engineers had at least three engineering managers who might need to be involved in one team's disagreement — escalating to a director if they could not agree.
• The coach's own words on chapter leads: they “don't really work with any team… They aren't taking that responsibility.”
• And his retrospective: “If I were to do one thing differently, I would say we should not be focusing so much on autonomy… Maybe, just maybe, we should have a minimum viable agility.”

The honest synthesis, and it is more useful than either the framework pitch or the cynical dismissal: coordination cost is conserved. You can pay it inside a team through hierarchy, or across teams through dependencies and negotiation. Every organisational design is a choice about where to pay it, and no design removes it.

So the question to ask about any proposed structure is not ‘is this agile?’ but “where does this move the coordination cost, and who owns it once it moves?” The Spotify story is what happens when the answer to the second half is nobody.