The Agile Lie

Most large organizations did not adopt Agile. They adopted the appearance of Agile.

There is a difference, and it matters enormously — because the engineers sitting in your standups, writing user stories, and estimating in story points can feel it. They feel it every single day. And it is a significant part of why they stop caring.

Here is what actually happened at most large companies that went through an “Agile transformation.”

Leadership decided the organization needed to move faster. Competitors were ahead. Something had to change. The answer, almost universally, was Agile. A consulting firm was brought in. There was a presentation. There was enthusiasm about “ways of working.”

Then came the pilot.

The pilot team was set up carefully — cross-functional, empowered, given an actual problem to solve rather than a list of requirements handed down from a business analyst. They had access to the people they needed. Obstacles were removed in real time.

Of course it worked.

A self-contained team with every skill it needs, empowered to solve a real problem, with obstacles actively removed — that team is going to deliver. That is not a controversial statement. That is just what happens when you create the conditions for good work.

The problem came next. When the pilot succeeded, leadership decided to scale it. But what they chose to scale was not the conditions that made the pilot work.

It was the rituals.

The two-week sprints. The story points. The standups. The retrospectives. Every team in the organization was going to do Scrum — including the teams for whom Scrum made no sense whatsoever.

I watched this happen firsthand at a national bank. The mainframe engineering teams — disciplined, careful teams doing procedural work with quarterly release cycles and months-long testing processes — were told they were going to run two-week sprints.

At the end of each sprint, they were expected to demonstrate “working software” and deliver “value.” But the software was not going to reach production for another two and a half months, minimum. The feedback loop that makes Agile meaningful — build something, ship it, watch it perform, learn, adjust — simply did not exist for these teams.

So what did they do? They did what rational people do when forced to perform in a system that doesn’t fit their reality: they performed. They learned to write stories that demonstrated “value” on paper. They crafted “As a user, I want...” statements for backend infrastructure work that no user would ever directly touch. They held ceremonies that felt meaningless because they were meaningless in that context.

Meanwhile, I was on a team building APIs for the bank’s credit card partners. Two-week sprints made sense for us. We could build quickly. Pipelines existed. The consulting firm’s playbook fit our work.

But we had our own version of the trap.

All of our credit card data lived on the mainframe. Any change touching that data required a deployment from the mainframe team — the team that released quarterly. We could build in two-week sprints. We just couldn’t always release.

What this produced was not a failure of process. It was a new and exhausting form of project management that nobody had planned for. Before anyone could begin a piece of work, the first question was always: does this change touch the mainframe? If yes, it had to be scheduled around a quarterly release window. If no, it could proceed — but carefully, because releasing the wrong thing at the wrong time meant shipping something incomplete or breaking a dependency that hadn’t landed yet.

So the team’s energy — the energy that was supposed to go into building and solving problems — went instead into dependency mapping. Sorting changes into buckets: mainframe or not, ready or waiting, safe to release or hold. The cognitive overhead of managing that inventory was invisible work. It never showed up in a velocity chart. It never surfaced in a retrospective.

It was just the constant background hum of a team doing Agile ceremonies on top of a waterfall dependency structure.

This is what I mean by the Agile lie. Not that Agile is wrong. Not that the consultants were frauds. But that most large organizations import the ceremonies of Agile while preserving the infrastructure of waterfall.

And the most important piece of waterfall infrastructure is the budget.

Finance departments at large companies have not figured out how to budget for true Agile development. They budget for projects. They have deadlines. They have annual planning cycles that define what gets funded, for how long, and with what expected deliverable. These constraints do not disappear because engineering teams start calling their work “sprints” instead of “phases.”

What you end up with is teams working in two-week sprints, running standups, estimating in story points — and implementing projects that were defined by leadership six months ago, with fixed scope and fixed deadlines.

The engineers are doing Scrum. The organization is still doing waterfall. These two things are in direct conflict. And the engineers feel that conflict every single day.

There is a layoff that happened during that first transformation that I think about often.

The Agile rollout happened at the same time as a significant restructuring. Engineers had to bid for their own jobs. There was a day where people sat at their desks and waited. You would watch a colleague get tapped on the shoulder and escorted to HR. By the end of the day, you would find out whether you still had a position.

That day taught every engineer in the building exactly what kind of environment they were now working in.

Stay quiet. Don’t stand out. Do what you’re told and survive.

This is the opposite of ownership. And it happened on the same week everyone was being told to embrace Agile’s values of self-organization, autonomy, and continuous improvement.

The colleagues who were let go were often the ones who had carried the unglamorous work — production support, regulatory maintenance, the labor of keeping systems running. That work did not disappear because the people doing it did. The remaining engineers were expected to deliver new features in two-week sprints and manage the production support burden with reduced headcount.

Retrospectives became performative. Engineers learned that the path of least resistance was to write the story, attend the ceremony, and wait to be told what to build next.

The passivity was not a personality trait. It was a rational adaptation to an irrational system.

One of the consultants from that transformation said something to me that I have never forgotten.

He said: “If your team is doing everything the same way in a year, then we have failed in understanding what Agile’s real benefit is.”

He was right. The real benefit of Agile is not sprints or story points or any ceremony. It is quick feedback loops. Continuous improvement. The discipline of testing things out, watching what happens, and adjusting based on what you learn. It is delivering value to real customers and using their response to guide what you build next.

The organization had looked at his framework and seen a process to install. He had meant it as a mindset to cultivate.

That gap — between Agile as a set of rituals and Agile as a philosophy of learning — is where passive engineers are made.

If you manage engineers inside a large organization and you recognize what I’m describing, the passivity you’re seeing in your team is not a character flaw. It is a message. The system produced the behavior.

The system can be changed — not all of it, but enough. That is what my first post was about, and it is what the book I wrote goes into in depth.

The ceremonies are not the point. The conditions are.