One Flew Over the Cuckoo’s Nest: The Escape from Agile

In One Flew Over the Cuckoo’s Nest, the story is set inside a psychiatric institution run not for healing, but for control. The ward is orderly, predictable, and calm on the surface. Patients follow rigid routines. Group therapy sessions exist, but nothing meaningful ever changes. Any behaviour that challenges the system is treated as dangerous. Non conformity is labelled dysfunction. Over time, the patients lose confidence in their own judgment and begin to police themselves.

The most disturbing part of the film is not the cruelty. It is the learned helplessness. The patients eventually cannot imagine life outside the ward. Even when escape is technically possible, the institution has already done its work. It has removed their ability to think independently.

Agile and SAFe followed the same arc.

What started as a rebellion against heavyweight, bureaucratic delivery models quietly became an institution of its own. Ceremonies replaced thinking. Compliance replaced judgment. And teams learned that it was safer to follow the routine than to ask whether the routine still made sense.

The tragedy is not inefficiency. The tragedy is that agile lobotomised teams.

Red carpet treatment for the Trojan Horse

Agile and SAFe turned out to be a Trojan horse.

We welcomed it willingly. We embraced the principles, the philosophy, the promise of empowered teams, faster feedback, and less bureaucracy. Compared to the heavyweight processes that came before, agile felt humane, pragmatic, even rebellious.

The danger was never the principles on the outside, but the machinery hiding inside them.

Once agile crossed the drawbridge, it did not stay small. It unpacked ceremonies, roles, artefacts, certifications, governance layers, and an entire industry dedicated to telling us we were “doing it wrong”. The principles were quietly replaced with rituals. Judgment was replaced with compliance. Thinking was replaced with process adherence.

By the time teams realised what had happened, the gates were already closed.

Questioning the system became heresy. Removing ceremonies was labelled risky. And any failure was blamed not on the model itself, but on insufficient belief, insufficient coaching, or insufficient adoption.

The Trojan horse did not destroy delivery overnight. It did something far more effective. It convinced teams that this was what good looked like.

1. The Lobotomy: How Agile Stopped Teams Thinking

After years inside the agile ward, many teams can no longer imagine how work would happen if you removed the rituals.

Take away the stand ups, sprint planning, refinement, retrospectives, PI planning, demos, and governance layers and there is genuine anxiety. Silence. Confusion.

So they ask the question the institution has trained them to ask:

“If not agile, then what?”

This is the wrong question.

It is the question of someone who has been conditioned to follow a routine, not to reason about outcomes.

The correct question is the one the institution discourages:

How do we ship product better?

Shipping product is the equivalent of leaving the ward. It means ideas becoming working software in the hands of users. It means learning from production, not from meetings. It means optimising for flow, safety, and speed, not for audit friendliness or ritual compliance.

When teams ask “if not agile then what?”, what they are really saying is that the process has become their operating system. Remove it and they no longer know how to think about work.

That is institutionalisation.

Agile did not just add overhead. It replaced judgment with ritual. Over time, the rituals stopped being a means to an end and became the end itself.

2. Enter the Ward: Sit With the Team

In the film, escape does not begin with policy reform. It begins with someone walking the floor and seeing the reality.

Do the same.

Sit with the team. Watch how work actually moves. Ignore Jira. Ignore reports. Ignore governance decks. Follow a single piece of work from idea to production and observe how often it stops moving.

Then ask the questions institutions avoid.

What constraints are slowing you down? Which of these are real, and which exist simply because nobody has challenged them? Can they be engineered out rather than managed around?

What tools are missing, broken, or imposed? Tooling friction compounds just like technical debt, yet most organisations pretend it is neutral.

Can the team make decisions without escalation? If every meaningful decision requires permission, speed is impossible regardless of how many ceremonies you run.

Do they understand the business they operate in? Not the project. The business. Revenue, costs, clients, regulation. Teams without context optimise locally and damage the whole system.

If something goes wrong, will testing catch it? Or will a customer discover it first? Testing is not about quality. It is about moving fast without fear.

Do they have real observability? When production breaks, can they see it immediately, understand it, and fix it without a war room? If not, your deployment frequency is capped.

Is the team composition correct for the task? Many teams are full of supervisors and coordinators, but short on people actually building, testing, and operating the system. This is organisational sedation masquerading as structure.

3. Hand the Keys Back to the Patients

In the film, control is maintained by denying agency. Agile does the same, just with nicer language.

To escape, you have to reverse that.

Once you have completed a deep review of constraints, stop prescribing solutions. Ask the team, and each functional area within it, to propose how they will ship product going forward.

Not how they will comply. How they will ship.

Their proposal should explain how work is shaped, how it flows, how it is tested, how it is deployed, and how failure is detected and handled.

Your job is not to standardise this across the organisation. Standardisation is how institutions defend themselves. Your job is to ensure the approach is coherent, safe, and aligned to outcomes.

Make one thing explicit: the change must be evolutionary. Big bang transformations are just another form of institutional violence. They create fear, surface compliance, and quiet sabotage.

Tell the team this clearly: we will adjust every four months based on what we learn. Nothing is permanent. Nothing is sacred.

That sentence removes fear. It replaces performative alignment with honest experimentation.

4. Nurse Ratched and the Tyranny of Order

In One Flew Over the Cuckoo’s Nest, Nurse Ratched is not a monster because she is cruel. She is a monster because she is calm, procedural, and unwaveringly committed to order.

Everything is justified as being “for the good of the patients”. Every routine is defended as necessary. Any challenge to the system is reframed as dangerous, immature, or non compliant. Agile organisations create their own Nurse Ratcheds.

They are not villains. They are process enforcers who value predictability over progress, rules over reasoning, and compliance over outcomes. Their job is to maintain the routine, not to question whether the routine still makes sense. This is how waste becomes untouchable.

Meetings exist because they exist. Governance forums approve nothing but consume hours. Status packs are produced laboriously, yet are often inconsistent, contradict the previous updates and almost everyone ignores them.

Large packs are the medication of corporate life. They sedate leadership into feeling they are informed, while quietly masking the death of meaningful delivery speed.

When teams question these rituals, they are told they “don’t understand agile”, that the process is “there for a reason”, or that removing it would be “risky”. This is exactly how institutions protect themselves.

Ask the team to keep notes throughout the cycle. Not complaints. Observations.

Which meetings create decisions?
Which artefacts actually change outcomes?
Which processes exist purely to maintain a sense of control? Do not punish this honesty. Reward it.

In institutions, silence is mistaken for alignment. In reality, silence is usually learned helplessness.

5. Break the Illusion of Safety

Now do what the institution fears most. Change the frame.

Tell the team to imagine they are running a business competing directly with another company. The client can leave at any time. There is no captive demand. No internal protection. No tolerance for excuses.

Would you still design your delivery system this way?

This framing does what frameworks never can. It reconnects work to reality.

Then say the sentence most teams have never heard:

We can change anything.

Agile did not free teams. It taught them where the invisible fences were and how not to touch them.

6. The Agile Industrial Complex

The Agile Industrial Complex is not an accident. It is a business model.

An entire economy of certifications, consultants, coaches, assessors, and tooling vendors depends on agile never actually working. If teams could ship software simply, safely, and frequently, the market for transformation would evaporate overnight. So instead, complexity is engineered, branded, and sold back to organisations as maturity.

SAFe is not complex because software is complex. Software has always been complex. SAFe is complex because simplicity does not justify billable hours. It does not sustain multi year roadmaps, certification pyramids, or armies of “change agents”. You cannot build a consulting empire on a two page set of principles and a competent engineering team.

Every failure is reframed as insufficient adoption. Every slowdown is treated as a coaching problem. When delivery stalls, the answer is never fewer roles, fewer ceremonies, or better engineers. The answer is always another workshop, another assessment, another layer of governance.

In the Agile Industrial Complex, teams are the product, leadership fear is the demand signal, and shipping software is incidental. The system is not broken. It is working exactly as designed.

7. “But It Works for Mature Teams”

This is the most common defence of agile and SAFe: “It works for mature teams.” That argument collapses under its own weight.

Any framework that only works for teams that already know what they are doing is, by definition, not doing any real work. High performing, experienced teams will succeed under almost any set of constraints. They will route around bad process, ignore pointless ceremonies, and quietly do what needs to be done despite the framework, not because of it.

The real test of a framework is not whether it gets out of the way of excellent teams. It is whether it elevates average teams, supports inexperienced teams, and provides a clear path for those who do not yet know how to ship product safely and effectively.

At an enterprise level, this matters even more. Most organisations are not made up entirely of elite teams. They are made up of mixed capability, uneven experience, and varying levels of leadership maturity. A framework that burdens the least skilled with ceremony, process overhead, and compliance tasks while claiming success when senior teams quietly ignore it is next to useless.

Frameworks should not punish teams for being inexperienced. They should reduce cognitive load, provide guardrails, and make the right thing easier to do than the wrong thing. They should teach judgment, not replace it with ritual. They should pave a path forward, not demand belief before results.

If a framework only works once teams are already mature, then the framework is not a solution. Frameworks should provide predictability, not predictable failure.

8. Choose the Escape Routes That Actually Work

From the constraints, waste, and proposals, you will have a list of potential changes. Do not treat them equally.

Rank each item on three dimensions.

How hard is it to change?

How much risk is there that it will go wrong?

How long will it roughly take?

This is not about precision. It is about judgment.

Target high yield, low risk, short duration changes first. These become oxygen. They free time, reduce friction, and rebuild belief.

The team needs to win early. Momentum matters more than theoretical optimisation.

Do not start with high risk, long duration changes. That is where transformation programmes go to die quietly, buried under good intentions and governance.

9. The Escape Is Not Chaos. It Is Sanity.

This is not anti process. It is anti fiction: stop performing work and start doing it.

You will still have structure. You will still have rules. But they will emerge from reality rather than being imposed to preserve the institution.

Agile and SAFe failed because they engineered defensibility, not delivery. They created a system that protects itself while starving teams of the conditions required to move fast and safely.

The alternative is not another framework.

The alternative is leadership willing to walk into the ward, unlock the doors, remove constraints, and accept that control and outcomes are not the same thing.

Stop asking what replaces agile. Start asking how you ship better products, faster. That is the real escape.

One thought on “One Flew Over the Cuckoo’s Nest: The Escape from Agile”

  1. This has truly opened my eyes to a lot! Thank you for this and the previous piece discussing Agile. Wow wow wow.

Leave a Reply

Your email address will not be published. Required fields are marked *