Study finds 268% higher failure rates for Agile software projects

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.”