Or: How We Turned Software Development Into Ticket Farming and Ceremonial Theatre
1. Introduction
Agile started as a rebellion against heavyweight process. It was meant to free teams from Gantt charts, upfront certainty theatre, and waterfall failure modes. Somewhere along the way, Agile became exactly what it claimed to replace: a sprawling, defensible process designed to protect organisations from accountability rather than deliver software.
Worse, every attempt to fix Agile has made it more complex, more rigid, and more ceremonial.
2. Agile’s Fatal Mutation: From Values to Frameworks
The Agile Manifesto was never a methodology. It was a set of values. But values do not sell consulting hours, certifications, or operating models. Frameworks do.
So Agile was industrialised.
We now have a flourishing ecosystem of Agile frameworks, each promising to scale agility while quietly suffocating it. SAFe is the most egregious example, but not the only one. These frameworks are so complex that they require diagrams that look like subway maps and multi day training courses just to explain the roles.
When a process designed to reduce complexity requires a full time role just to administer it, something has gone badly wrong.
Framework proliferation map showing how Agile spawned more governance than it replaced.
3. The Absurdity of Sprints
Few terms expose Agile’s intellectual dishonesty better than sprint.
A sprint is supposedly about speed, adaptability, and urgency. Yet in Agile practice, it is a fixed two week time box, planned in advance, estimated upfront, and reviewed retrospectively. There is nothing sprint like about it.
Calling a two week planning cycle a sprint is like calling a commuter train a race car.
Agile claims to embrace change, yet its core execution model actively resists it. Once work is committed to a sprint, change becomes scope creep rather than reality. The language is agile; the behaviour is rigid.
The sprint paradox showing fixed time boxes masquerading as agility.
4. SAFe™ and the Industrialisation of Complexity (2026 Reality Check)
If SAFe™ was already bloated, the 2026 updates pushed it into full blown institutional absurdity.
The framework did not simplify. It did not converge. It did not correct course. It expanded. More roles. More layers. More artefacts. More synchronisation points. Every release claims to “reduce cognitive load” while aggressively increasing it.
SAFe™ in 2026 is no longer a delivery framework. It is a consulting extraction model.
4.1 Complexity Is the Product
The defining feature of modern SAFe™ is not agility. It is deliberate complexity.
The framework is now:
- Too large for leadership to understand
- Too abstract for engineers to respect
- Too entrenched to remove once adopted
This is not accidental design failure. This is commercial optimisation.
SAFe™ is engineered to require:
- Continuous certification
- Ongoing retraining
- Specialist roles that only external consultants can interpret
- Diagrammatic sprawl that requires facilitation just to explain
If a framework needs paid interpreters to function, it is not a framework. It is a revenue stream.
4.2 Predatory Economics and Executive Ignorance
The 2026 SAFe™ model preys on a structural weakness in large organisations: technical illiteracy at the top.
Executives who do not understand software delivery are uniquely vulnerable to frameworks that look sophisticated, sound authoritative, and promise control. SAFe™ exploits this perfectly.
It sells:
- Alignment instead of speed
- Governance instead of ownership
- Artefacts instead of outcomes
- Process instead of production
Large consultancies thrive here. They do not fix delivery. They prolong transformation. Every new SAFe™ revision conveniently creates new problems that only certified experts can solve.
This is not transformation. It is dependency creation.
4.3 Safety Theatre for Leadership
SAFe™ does not optimise for delivery. It optimises for defensibility.
When delivery fails, leaders can say:
- We followed the framework
- We invested in training
- We implemented best practice
- We had alignment
Responsibility dissolves into ceremony.
SAFe™ provides political cover. It allows leadership to appear decisive without being accountable. Failure becomes systemic, not personal. That is its real value proposition.
4.4 Role Inflation as a Symptom of Collapse
The 2026 updates doubled down on role inflation:
- More architects to manage architectural drift
- More product roles to manage backlog confusion
- More portfolio layers to manage coordination failure
- More councils to manage decision paralysis
Each new role exists to compensate for the damage caused by the previous role.
This is not scale. This is organisational recursion.
4.5 Why SAFe™ Cannot Be Fixed
SAFe™ cannot be simplified without destroying its economic model.
If it were reduced to:
- Small autonomous domain teams
- Clear end to end ownership
- Direct paths to production
- Continuous deployment
There would be nothing left to certify. Nothing left to consult. Nothing left to sell.
So complexity grows. Terminology mutates. Diagrams expand. Billable hours increase.
This is not a failure of SAFe™.
This is SAFe™ working exactly as designed.
SAFe complexity diagram illustrating role and process sprawl
5. Alignment Is a Poor Substitute for Velocity
Agile frameworks obsess over alignment. Align the teams. Align the backlogs. Align the ceremonies. Align the planning cycles.
Alignment feels productive, but it is not speed.
True velocity comes from segregation and autonomy, not synchronisation. Teams that own domains end to end move faster than teams that are perfectly aligned but constantly waiting on one another.
Alignment optimises for consensus. Autonomy optimises for outcomes.
In practice, Agile alignment produces shared delays, shared dependencies, and shared excuses. Velocity dies quietly while everyone agrees on why.
6. Agile as a Ticket Collection System
Modern Agile organisations are not delivery machines. They are ticket processing plants.
Engineers spend an extraordinary amount of time creating tickets, grooming tickets, estimating tickets, updating ticket status, and explaining why tickets moved or did not move.
This is administrative work wrapped in the language of delivery.
Burn down charts are the pinnacle of this illusion. They show activity, not value. They measure compliance with a plan, not impact in production. They exist to reassure stakeholders, not users.
The ticket lifecycle showing how work multiplies without increasing value.
7. Burn Down Charts Are a Waste of Time
Burn down charts answer exactly one unimportant question: are we progressing against the plan we made two weeks ago?
They tell you nothing about whether the software is useful, whether users are happier, whether the system is more stable, or whether deployment is easier or safer.
They are historical artefacts, not decision tools. By the time a burn down chart reveals a problem, it is already too late to matter.
8. Engineer the Path to Production, Not a Defensible Process
Agile made a critical mistake: it focused on process before engineering.
Real agility comes from automated testing, trunk based development, feature flags, observability, continuous integration, and continuous deployment.
You do not become agile by following a defensible process. You become agile by engineering a path to production that is boring, repeatable, and safe.
A release pipeline beats a retrospective every time.
9. Continuous Deployment Is What Agile Pretends to Be
If agility means responding quickly to change, then continuous deployment is agility in its purest form.
No sprints
No ceremonies
No artificial planning cycles
Just small changes, shipped frequently, with fast feedback.
Continuous deployment forces discipline where it matters: in code quality, test coverage, and system design. It removes the need for most Agile theatre because progress is visible in production, not on a board.
Infographic placeholder (JPEG):
Sprints versus continuous deployment showing time boxed delivery versus continuous flow.
10. Domains Beat Ceremonies
The most effective organisations do not scale Agile. They decouple themselves.
They organise around business domains, not backlogs. Teams own problems end to end. Dependencies are minimised by design, not managed through meetings.
This reduces coordination overhead, alignment ceremonies, and cross team negotiation, while increasing accountability, speed, quality, and ownership.
No framework can substitute for this.
11. Conclusion: Agile Isn’t Dead, But It Should Be
Agile failed not because its original ideas were wrong, but because organisations turned values into process and flexibility into dogma.
What remains today is ceremony without speed, alignment without autonomy, measurement without meaning, and process without production.
Agile did not make organisations adaptive. It made them defensible.
Real agility lives in engineering, autonomy, and production reality. Everything else is theatre.