Study finds 268% higher failure rates for Agile software projects

Original Article ↗ Hacker News Discussion ↗

A paywalled article claiming Agile software projects fail 268% more often than waterfall prompts strong skepticism, with many noting the “study” was commissioned to market a rival methodology and appears riddled with selection bias and vague definitions of success. Commenters argue that what usually fails is cargo-cult Agile—meeting-heavy, requirements-light processes misbranded as Agile—rather than the Agile Manifesto’s principles themselves, and that clear requirements, good communication, and appropriate methodology choice matter more than any branded framework.

Study credibility and methodology

  • Many see the “268% higher failure rate” claim as marketing for a competing methodology (Impact Engineering), not neutral research.
  • The underlying survey and data are not shared; methodology (sample, questions, definitions) is unclear.
  • Several note strong selection bias: risky, underspecified, or experimental projects are more likely to use “agile,” while critical, well‑funded efforts skew to waterfall.
  • The study’s definition of “Agile Requirements” (unclear specs, late changes, starting before requirements) is criticized as a list of risk factors, not a faithful description of agile.

Definitions of success and failure

  • Success is apparently defined by the “iron triangle” (time, budget, scope). Commenters argue this ignores business value and learning.
  • Fast, cheap project cancellation can be a better outcome than a “successful” but useless two‑year build.
  • Some suspect the bar for “failure” is so low that minor overruns are counted.

Agile vs. waterfall and domain fit

  • Thread consensus: no single methodology fits all.
  • Waterfall or V‑model are seen as better for safety‑critical, tightly specified systems (hardware control, aerospace, medical, ISS, etc.).
  • Agile/iterative approaches are favored where requirements are uncertain or highly changeable (startups, CRUD apps, internal tools).

Agile in theory vs. practice

  • Many distinguish the Agile Manifesto (“small‑a agile”) from capital‑A Agile/Scrum as practiced.
  • Core manifesto ideas (iterative delivery, tight feedback loops, self‑organizing teams, user collaboration) are widely liked.
  • Real‑world “agile” often means: no upfront design, weak requirements, little testing, rigid ceremonies, and management‑driven deadlines—seen as cargo cult or “consultant agile.”
  • Some argue that if 90% of implementations are “wrong,” the system itself may be unfit or too vague, creating a “No True Scotsman” dynamic.

Requirements, documentation, and scope

  • Many agree with the study that clearer requirements correlate with success, regardless of methodology.
  • Several stress agile never meant “no requirements/documentation,” only “don’t over‑optimize docs at the expense of working software.”
  • Scope creep and unstable requirements are repeatedly cited as major failure drivers independent of process.

Meetings, management, and developer experience

  • Common complaints: excessive ceremonies, long daily standups, and use of agile as a micro‑management and reporting tool.
  • Psychological safety, good requirements engineering, and the ability to adapt the process are viewed as more important than the label “agile” or “waterfall.”