Thirty Years of Agile and Software Success Is Still Stuck at 31%

About 31% of software projects succeed. Half are "challenged" – late, over budget, or stripped of scope to limp across the line. The remaining fifth fail outright.

Those are the latest Standish CHAOS figures, summarized in a January 2026 analysis, and the thing worth sitting with isn't the 31%. It's that the number has barely moved in a decade – up from roughly 29% in the prior dataset. In the years between those two measurements the industry adopted Agile at scale, moved to the cloud, standardized CI/CD, and bolted AI onto everything. The success rate responded with a shrug.

That should bother anyone who's spent money on a transformation. We changed almost everything about how software gets built and the outcome stayed flat. Either none of it worked, or we've been treating the wrong bottleneck.

The methodology wasn't the constraint

It's the second one. The tools and methods worked fine at the thing they target – writing, testing, integrating, and shipping code. What they don't touch is where the failures actually live.

The same analysis makes the point plainly: the root causes of failure have "shifted from process execution to strategic alignment and data governance." Look at the consistent culprits and they're all upstream of the IDE. PMI's research has long put scope creep on a majority of projects – 52% in one widely cited figure – and inaccurate requirements behind a large share of failures. None of that is a coding problem. Agile makes a team faster at building; it does nothing to guarantee they're building the right thing, or that anyone agreed what "right" was before the sprint started.

There's a second tell in the data, and it's almost too on-the-nose: small projects succeed around 90% of the time, large ones less than 10%. Size is one of the strongest predictors of failure there is. That's not a statement about tooling either – it's a statement about how much ambiguity, coordination, and unvalidated assumption a project is carrying. Big projects fail more because there's more room for the upstream stuff to go wrong, and no amount of velocity saves you from building the wrong large thing efficiently.

Why better tools keep not fixing it

This is the part that explains the flat line, and it's why I'd be skeptical of the next tool that promises to move it. Every wave of tooling optimizes execution – the part that was already, comparatively, working. None of them touch the decisions that happen before and around the code: what problem are we solving, do the people funding it and building it agree, is the scope honest, who decides when reality diverges from the plan.

AI is about to repeat the pattern in a bigger way. It makes producing software dramatically cheaper, which means it makes producing the wrong software dramatically cheaper too. If your 31% was capped by weak alignment and fuzzy requirements, faster code generation doesn't raise the ceiling. It just lets you hit it sooner.

The teams that actually beat the average aren't the ones with the best tooling. They're the ones who do the unglamorous upstream work: getting real agreement on the problem before building, keeping scope honest as it tries to drift, naming who makes the call when the plan meets the world, and shrinking the project until it's small enough to actually succeed.

Three decades of evidence say the tools were never the thing holding you back. The number's been trying to tell us that the whole time. It's worth finally listening before the next wave of tooling gets the credit – or the blame – for a problem it was never going to solve.