I’ve spent years watching organizations rebrand their dysfunction.
They change “Project Manager” to “Scrum Master.” They swap “requirements documents” for “user stories.” They start calling their status meetings “stand-ups.”
Then they wonder why nothing actually changes.
The numbers tell a brutal story. 65% of software projects adopting agile requirements engineering practices fail to deliver on time, within budget, and to a high standard of quality. That’s a 268% higher failure rate compared to projects that don’t adopt these practices.
Read that again.
Agile projects fail at nearly three times the rate of traditional projects when implemented poorly. The methodology designed to fix software development is now breaking it worse than before.
The Contract Problem Nobody Talks About
Here’s what I’ve noticed: most agile transformations stop at the development team.
The developers adopt Scrum. They run sprints. They hold retrospectives. But the contract governing the entire relationship? That’s still pure waterfall.
You have fixed deliverables. Fixed timelines. Fixed budgets. And a procurement process that demands you know exactly what you’re building before you’ve learned anything about the problem.
The contract says “agile” but enforces rigidity.
Between 47% and 96% of agile transformations fail to generate the capability to adapt to changing market conditions. And 67% of these failures are terminal, meaning bankruptcy or acquisition.
Two decades after the Agile Manifesto, organizations are still getting this catastrophically wrong.
When Agile Methodology Meets Waterfall Governance
The UK’s Horizon IT system offers a perfect case study in agile implementation disaster.
This was one of the earliest large-scale projects to use an agile methodology. It led to the wrongful prosecution of hundreds of post office workers. Fujitsu engineering witnesses condemned the approach as a cause of technical problems due to the absence of a robust requirements engineering process.
One technical expert summarized it simply: “If you don’t have a good design, it’s not going to work properly.”
The agile label didn’t save them. The superficial adoption of methodology without the underlying principles destroyed the project.
I’ve seen this pattern repeat across industries. Organizations layer agile terminology over existing waterfall governance structures. They mandate Scrum use in technology departments while keeping phase-gate processes everywhere else.
The result? What practitioners cynically call “Fragile.”
What Fragile Looks Like in Practice
You recognize Fragile when you see it:
- Customers don’t show up to scrums because the contract doesn’t require their participation
- Endless sprints continue because defects aren’t properly managed
- Stakeholders reject what’s delivered despite minimal engagement throughout development
- Teams measure success by whether they continue getting funding, not whether they deliver necessary functionality
A Department of Veterans Affairs project manager once stated: “The project was never in crisis since they were spending the entire budget every year.”
That’s the measurement trap. When your contract incentivizes spending over delivering, you get exactly what you’ve incentivized.
The Documentation Paradox
The Agile Manifesto declares “working software over comprehensive documentation.”
Organizations took this to mean “no documentation.”
The data shows how badly this backfired. Projects with specification or documented requirements before development started were 50% more likely to succeed than those without. Projects with clear requirements before starting development were 97% more likely to succeed.
The manifesto said “over,” not “instead of.”
But when your contract structure doesn’t support iterative discovery, teams abandon documentation entirely. They claim agile principles while actually just skipping the hard work of understanding what they’re building.
Surrey Police Force learned this lesson the expensive way in 2005. They embarked on an agile project to replace their crime and intelligence systems with zero experience in agile methodology.
Despite constant customer feedback opportunities, developers didn’t deliver a single accepted module. The project took three times as long as anticipated and came in five times over budget. They eventually reverted to waterfall methodology, where significant integration issues were discovered.
The agile contract failed because it wasn’t actually agile. It was waterfall with shorter deadlines.
The Risk Allocation Problem
Traditional fixed-price contracts reduce agility and make producing valuable products harder.
Time-and-materials contracts shift all risk to the customer.
Most organizations pick one of these terrible options and call it agile contracting. They continue contracting with suppliers using waterfall-minded techniques even after adopting agile for delivery.
This creates a fundamental mismatch that dooms projects before they begin.
I’ve watched procurement departments demand detailed specifications for agile projects. They require vendors to commit to features, timelines, and costs before anyone understands the problem space. Then they’re surprised when the delivered solution doesn’t match actual needs.
The contract focused on inputs rather than outcomes. It optimized for compliance rather than value.
What Actually Works
Real agile contracts require a different foundation:
- Shared risk and reward structures that align vendor and customer incentives
- Outcome-based success metrics instead of feature checklists
- Mandatory customer participation with defined roles and responsibilities
- Flexible scope within fixed time and budget constraints
- Regular decision points where either party can adjust or exit
But here’s the challenge: many past attempts at agile contracting appear to customers as “no contract at all.” They get rejected as theoretical ideals because they require trust that traditional procurement processes explicitly avoid.
You can’t build trust through contract clauses. You build it through behavior.
The Enterprise Struggle
90% of companies struggle to deliver an enterprise-wide agile transformation.
The failure stems from not undertaking genuine transformations. Organizations rebrand existing processes. They change titles. They adopt new terminology. But the underlying system remains unchanged.
Simply mandating Scrum use in technology departments while maintaining waterfall governance everywhere else is insufficient. The contract structure has to change. The procurement process has to change. The way organizations measure success has to change.
Everything has to change, or nothing actually changes.
I’ve seen organizations spend millions on agile coaching while their legal department continues writing contracts that penalize adaptation. They train teams on iterative development while their finance department requires annual budget commitments to detailed feature lists.
The dysfunction isn’t in the methodology. It’s in the mismatch between methodology and governance.
What This Means for You
If you’re implementing agile, your contract is either your biggest asset or your biggest liability.
Look at how you’re structuring agreements with vendors, partners, and internal teams. Ask yourself:
- Does this contract enable or prevent adaptation?
- Do our success metrics measure outputs or outcomes?
- Have we aligned incentives between all parties?
- Can we change direction when we learn something new?
- Does customer participation have real teeth, or is it optional?
If your answers reveal waterfall thinking, you’re setting up for waterfall results. The agile label won’t save you.
The organizations succeeding with agile aren’t the ones with the best Scrum implementation. They’re the ones who rebuilt their entire contracting approach around collaboration, transparency, and shared responsibility.
They stopped pretending you can mandate agility through rigid agreements.
The choice is simple: transform your contracts or watch your agile transformation join the 65% failure rate. Because poorly implemented agile contracts don’t just fail differently than waterfall.
They fail exactly the same way.
