If you have ever had to pick between Agile and Waterfall for an outsourced project, you have probably heard some version of "Agile succeeds three times more often." That claim was shaky even before AI coding tools arrived. Now that AI writes a large share of the code, the question itself needs rethinking.
Every mainstream method, whether Waterfall, Agile, Scrum or Kanban, was designed for a world where writing code was the slowest, most expensive step. That is no longer true, and the bottleneck is moving somewhere else. This article looks at three things:
- what the popular success-rate figures actually measure
- how the contract you sign shapes the method you can realistically use
- what AI changes for each method, based on current research
The "3x more successful" statistic, and its fine print
The number most often quoted comes from the Standish Group's CHAOS report: 39% of Agile projects succeed, against 11% of Waterfall projects. On large projects the gap widens to 18% vs. 3% (PM Essentials).
The catch is the definition of success. CHAOS counts a project as successful if it lands on time, on budget and with all planned features, measured against the original estimate. Researchers Eveleens and Verhoef at VU University Amsterdam applied that same yardstick to 1,211 real projects and 5,457 estimates. Their verdict: the Standish figures do not reflect reality. They measure estimation accuracy, and they blend very different estimating practices into a single average (IEEE Software, 2010).
So before using the number in a business case, keep three caveats in mind:
- The gap shows up most clearly on large, high-uncertainty projects.
- Agile teams adjust scope as they go; Waterfall teams are judged against the scope they committed to up front. The two are not being held to the same bar.
- The follow-up research shows success rates depend heavily on how the original estimate was made.
It is also worth noting how uneven adoption still is. In Japan, one of the largest markets for software outsourcing, IPA's DX White Paper 2021 found that only 19.3% of surveyed companies use Agile development (@IT). A big reason is the way contracts are written.
Your contract decides more than you think
In outsourced development, the method is usually locked in the moment the contract is signed. Most contracts fall into one of two shapes:
| Fixed-price (in Japan: 請負, ukeoi) | Time & materials (in Japan: 準委任, jun-inin) | |
|---|---|---|
| The vendor commits to | Delivering a finished product that matches the spec | Doing the work with professional care |
| Scope risk sits with | The vendor | The client |
| It only works if | The spec is clear and frozen early | The client stays closely involved and makes decisions continuously |
| Natural method | Waterfall | Agile, Scrum, Kanban |
Japan offers a useful case study. In 2020, IPA (Japan's Information-technology Promotion Agency) published a model contract for Agile projects and deliberately based it on time-and-materials. The reasoning: features and priorities will change mid-project, so a fixed-price contract does not fit. IPA also made clear that the client has to take an active, substantial role, not hand the work off and wait (Publickey, IPA).
This explains much of the adoption gap. A fixed-price contract gives the client one budget number, which is easy to push through internal approval (in Japanese companies, the ringi sign-off process). Time-and-materials asks the client to carry scope risk and to keep a decision-maker available week after week. Many organizations are not set up for that.
In practice, teams often combine the two:
- Phased contracts: discovery and requirements on time-and-materials, then build on fixed-price once the spec is stable.
- Dedicated team: a long-term offshore team (often called a "lab" model in Japan) for products that evolve continuously.
What AI changes: code gets cheap, the spec gets expensive
Agile rests on one assumption: changing software late is costly, so build in small slices and catch mistakes early. AI coding tools change the cost curve behind that assumption.
Faster delivery, less stability. Google's 2025 DORA report found that 90% of software professionals now use AI and more than 80% say it has made them more productive. AI correlates positively with delivery throughput but negatively with delivery stability. And 30% still have little or no trust in AI-generated code (Google Cloud).
AI amplifies what is already there. DORA's central finding is that AI does not fix a weak team; it magnifies existing strengths and weaknesses. Apply that to requirements: a process with fuzzy requirements, sped up by AI, can simply produce more code that misses the point, faster.
The spec is back at the center. Give an AI agent a vague description and it will write code that looks right, runs, and still misses what you meant. That is why spec-driven development has gained ground in 2026. GitHub Spec Kit is one example; it structures the work as Constitution → Specify → Plan → Tasks → Implement (MarkTechPost).
Look at that sequence and it is essentially a miniature Waterfall: requirements, design, breakdown, build. The difference is that one cycle takes hours or days, not months.
Taken together, these sources point in one direction: the Agile-versus-Waterfall line is blurring into Waterfall-grade specs with Agile-length iterations. The hard work is shifting from writing code to defining requirements and reviewing output, which is the territory of Business Analysts and Product Owners.
A simple way to choose: two questions
Strip away the labels and the choice comes down to two questions: how clear are the requirements, and how involved will the client be?
The bottom-left cell, unclear requirements with a hands-off client, is where projects most often go wrong. None of the five methods solves it on its own; the usual fix is to run a business analysis or prototyping phase before committing to a build. For ongoing operations and maintenance, Kanban tends to be used whichever cell a project sits in.
The five methods at a glance, updated for AI
The last column summarizes how AI shifts each method, based on the sources above.
| Method | Strengths | Weaknesses | Typical contract | What AI changes |
|---|---|---|---|---|
| Waterfall | Predictable cost and schedule; full documentation, easy handover | Expensive to change the spec; you only see the product at the end | Fixed-price | A detailed spec is excellent input for AI agents, and AI makes early prototypes cheap enough to test the spec |
| Agile | Flexible; working software early | Scope and budget are hard to pin down; needs continuous client input | Time & materials | Code ships faster, and so does technical debt; strong automated testing becomes essential to keep things stable |
| Scrum | Clear rhythm; visible progress; built-in improvement | Falls apart without a real Product Owner; ceremonies can become box-ticking | Time & materials / dedicated team | Two-week sprints can feel long when AI finishes tasks in days; the bottleneck moves to the PO and to review |
| Kanban | Easy to adopt; handles unplanned work; exposes bottlenecks | Long-term goals and deadlines can drift | Time & materials | The most natural fit for AI-assisted maintenance: small tasks flow continuously, and "waiting for review" becomes the column to watch |
| Hybrid | Fixed budget with room to adapt; easier to get through internal approval | A fuzzy boundary between phases brings the downsides of both | T&M (requirements) + fixed-price (build) | The closest match to spec-driven development: detailed specs, short cycles |
Key takeaways
- The "Agile succeeds 3x more often" statistic measures how closely a project matched its original estimate, not the business value it delivered.
- The contract type and how involved the client can realistically be matter as much as the method itself.
- According to DORA 2025, AI speeds up delivery but comes with lower stability. The bottleneck is moving to requirements and review, so that is where outsourcing teams need to invest.
References
- Successful Projects: What We Really Know — PM Essentials (CHAOS figures)
- Eveleens & Verhoef, The Rise and Fall of the Chaos Report Figures — IEEE Software, 2010
- DX White Paper 2021: Agile adoption (Japanese) — @IT
- IPA model contract for Agile development (Japanese) — IPA
- IPA: quasi-mandate is the appropriate contract for Agile (Japanese) — Publickey
- Announcing the 2025 DORA Report — Google Cloud
- Meet GitHub Spec-Kit — MarkTechPost
