Agile has a reputation problem. Depending on who you ask, it's either the salvation of software delivery or the source of its dysfunction. Standups that waste everyone's morning. Sprints that deliver activity but not progress. Velocity charts that management loves and engineers distrust.

The critics aren't entirely wrong. But their diagnosis usually is.

The ceremonies aren't the problem. The problem is a specific, structural omission that almost every organisation makes, and it has been hiding in plain sight for years.

What Agile Actually Is

Before diagnosing what's broken, it helps to be precise about what Agile actually is at its core: a tight feedback loop.

  1. Deliver in small increments.
  2. Inspect the outcome honestly.
  3. Adjust direction.
  4. Repeat.

That's it. The ceremonies (standups, sprint reviews, planning sessions) exist to support this loop. They are scaffolding, not the structure. And this distinction matters enormously, because it means you can run every ceremony faithfully and still fail to do Agile at all.

Where Are We Today?

Most teams run the ceremonies. Standups happen. Sprints are planned and reviewed. Backlogs are refined.

And yet projects still drift, miss, and overrun. Stakeholders remain sceptical. Delivery feels unpredictable. The pushback is real and growing: Agile is rigid, it's bureaucratic, the business never really bought in.

These are genuine symptoms. But they're pointing at the wrong cause.

It also didn't happen by accident. A significant industry grew up around selling Agile: frameworks, certifications, tooling. The ceremonies became products, and products need to justify their existence. Hype creates inertia, and that inertia is still working against us.

Velocity metrics creating pressure without accountability: that's a management problem layered on top of Agile, not a property of Agile itself. Business stakeholders remaining sceptical because predictability was promised and not delivered: that's a planning problem. The formulaic feeling of ceremonies is what happens when the ceremony outlives the understanding of why it exists.

The underlying mechanism is still sound. Something else is broken.

The Retrospective Gap

Here's the specific thing that's broken: organisations run retrospectives at the team level and almost nowhere else.

Most teams retrospect after every sprint. It's table stakes at this point. But above the team (at the programme level, the portfolio level, the organisation level) retrospectives almost never happen.

In many years across multiple organisations, I can count the retrospectives above team level on one hand, and most of those were at startups small enough that every level was the team level. Talking to peers, this is not unusual. It appears to be the industry norm.

This gap is fatal to the whole system.

The retrospective is the only ceremony that closes the feedback loop. Without it, you're not doing Agile; you're doing a fast and loose version of Waterfall. Teams iterate, but the organisation cannot change direction. Decisions made at the portfolio level about scope, priority, and direction go uninspected. The unknowns that couldn't be resolved up front (and in complex projects, there are many) accumulate quietly until they surface as a failed delivery.

"Move fast" without course-correction is just moving fast in the wrong direction.

The Ego Problem

Agile is mechanically simple. The ceremonies are not hard to understand or run. So why does the retrospective disappear above the team level?

Because retrospectives are hard on the ego.

At the team level, a retrospective asks: did this sprint go well? What should we do differently next time? The stakes are relatively low. At the organisational level, a retrospective asks something much more uncomfortable: was the plan wrong? Did we make the right calls? Should we change direction?

In large organisations, being wrong carries career risk. Admitting that a programme-level decision was mistaken, publicly and in a formal setting, is an invitation for scrutiny. So the feedback gets suppressed. The plan gets defended. The loop stays broken.

This is not a process failure. It's a leadership and culture failure. And it's why fixing it requires more than introducing another velocity chart.

What It Looks Like When It Works

I saw this done well at a startup building a Customer Due Diligence (KYB) application. The team was small, just three developers, working on a problem domain that was genuinely complex and poorly understood at the outset. Ambitious scope, unpredictable requirements, and no realistic path to getting everything right up front.

A concrete example: we needed to build a record matching algorithm. The first attempt used LLMs. It didn't work well enough. Rather than defending the choice or spending more time optimising it, we called it and moved on. The second attempt used a fine-tuned BERT model to extract features. Also fell short. Again, we stopped, assessed, and changed direction.

The final approach was a largely hand-coded algorithmic system producing a detailed, fine-grained taxonomy. Unglamorous. Counterintuitive, given where the industry's attention was pointing. And it's now an increasingly successful product.

What made this possible wasn't exceptional technical skill, though the team had that. It was that each failed approach was treated as information, not failure. There was no sunk-cost defence. No one needed to be vindicated for having recommended LLMs. The only question at each retrospective was: what do we know now that we didn't know before, and what should we do differently?

That's the feedback loop working. That's Agile.

This was a small team. The feedback loop was short and the stakes were contained. Scaling this to an organisation is harder; I won't pretend otherwise. But the principle is identical, and the failure mode when you don't do it is identical too.

What an Organisational Retrospective Actually Looks Like

An organisational retrospective is not a team retrospective scaled up. The purpose is different. The participants are different. The questions are different.

It's triggered by major deliveries, significant misses, or a regular cadence; quarterly is a reasonable starting point. The participants are the people who made the programme and portfolio level decisions and the team product / engineering leads, not the teams who executed them.

The questions it must answer honestly:

  • Did we deliver what we set out to? If not, what were the real constraints: technical, organisational, or in our original assumptions?
  • Were our assumptions about the problem correct? What did we learn that we didn't know at the start?
  • What would we do differently at the programme or portfolio level?

The hard requirement is genuine psychological safety. Not the performative version. The real thing. If a retrospective is safe for everyone except the people who made the decisions, it is not safe. Leadership must model it.

  • Be wrong out loud.
  • Call your own decisons into question.

Make it clear that changing direction is a sign of good judgement, not weakness.

Summary

Agile's ceremonies are not the problem. Stop blaming the standup.

The feedback loop is broken at the organisational level because org-level retrospectives don't happen. Teams iterate within a system that cannot change direction, and the results are predictable: activity without progress, speed without accuracy, delivery without fit.

This is a culture problem before it's a process problem, and it lives with leadership. The fix isn't complicated: introduce retrospectives at every level, make them genuinely safe, and model honesty about being wrong from the top.

The feedback loop is Agile. Close the loop.