Agile’s Long Con: How a Software Manifesto Became Corporate Excuse-Making With Stand-Ups
The most savage line recently circulating in software circles is attributed to Alistair Cockburn, one of the original authors of the Agile Manifesto: Agile, he allegedly said, started as a cult and turned into a scam. I could not verify the exact wording from a primary Cockburn source, which matters, because the internet has a habit of converting irritation into quotation and quotation into scripture, yet the sentence survives because it captures something many engineers, product people, project managers, and exhausted adults trapped in Jira already know from lived experience. Agile began as a rebellion against bureaucratic software delivery, against dead documentation, against armies of managers who confused Gantt charts with thinking, and against the old corporate disease where nobody saw working software until the budget had already become archaeological material. Then, through the usual institutional miracle by which every anti-bureaucratic idea becomes a bureaucracy with certificates, workshops, role titles, consultants, rituals, laminated values, and people whose entire contribution to engineering is asking whether a ticket has acceptance criteria, Agile became exactly the kind of machine it once promised to destroy. The tragedy, or the comedy if your salary depends on selling transformation decks, is that the modern Agile industry sells speed while manufacturing delay, sells responsibility while diffusing accountability, and sells adaptability while often giving management a perfect excuse to avoid deciding what should actually be built.
The 2024 Engprax study, controversial though it is and worth treating with caution because Engprax is connected to the promotion of its own “Impact Engineering” framework, supplied the anti-Agile camp with a number too explosive to ignore: software projects adopting Agile Manifesto practices were reported as 268 percent more likely to fail than those doing the opposite, based on a survey of 600 engineers in the United Kingdom and the United States. The same research claimed that projects with documented requirements before development began were 50 percent more likely to succeed, projects with clear requirements before development were 97 percent more likely to succeed, and projects without significant late-stage requirement changes were more likely to succeed as well, which is an almost offensively obvious finding only in an industry that spent two decades pretending that ambiguity is a productivity strategy. The striking point here is less the exact coefficient, because any single study with commercial context deserves skepticism, than the direction of the evidence: when engineers know what problem they are solving, why it matters, what constraints define success, and which trade-offs have already been thought through, the project has a better chance than when everyone performs “collaboration” around a fog machine. Even critics of the Engprax paper have conceded that the failure signal may come from weak requirements, poor documentation, and bad project management disguised as Agile, which only sharpens the indictment, because that is precisely how Agile is usually consumed in the corporate wild.
The popular defense, usually delivered by someone with a certification logo in an email signature, says that failed Agile merely proves Agile was done wrong, which is a wonderfully unfalsifiable sentence and therefore beloved by every managerial priesthood in history. Communism failed because true communism was never tried, privatization failed because the market was distorted, central planning failed because the wrong people planned it, and Agile failed because the stand-up had insufficient psychological safety while the backlog grooming session lacked spiritual purity. This logic protects the framework by moving every failure into the user, the team, the culture, the maturity model, the leadership mindset, the tooling environment, the transformation roadmap, or the phase-two coaching budget. A methodology that requires unusually good leaders, unusually disciplined teams, unusually mature stakeholders, unusually stable priorities, unusually skilled product people, and unusually honest communication may be less a universal operating system and more a luxury good for organizations that were already capable of building things before the consultants arrived. The darker interpretation is that Agile became popular precisely because it lets every layer of management look modern while postponing the hard, expensive, reputation-risking act of making decisions.
This is where the Big Tech evidence becomes uncomfortable for the Agile priesthood, because the firms that supposedly represent the highest temple of modern software execution often borrow a few Agile artifacts while refusing the full corporate Scrum religion. Gergely Orosz, writing in The Pragmatic Engineer, described how project management practices differ widely across companies and highlighted the “curious absence of Scrum” in Big Tech, noting that teams at large technology companies often choose their own methods, while complex cross-team projects are frequently driven by technical program managers rather than ritualized Scrum machinery. His Skype versus WhatsApp example is brutal in miniature: Skype went heavily into Scrum, training, ceremonies, and rotational Scrum Master roles, while WhatsApp, with a smaller engineering organization, largely ignored heavyweight frameworks and still out-executed Skype in the messaging war. That does not prove Scrum kills companies, because markets are never that clean, yet it does suggest that process language, ceremony density, and visible managerial choreography should never be confused with engineering advantage. The best technology organizations tend to keep the useful parts, such as short feedback loops, clear ownership, incremental delivery, strong technical review, and fast correction, while rejecting the theater that turns software development into a recurring calendar tax.
Harvard Business Review had already hinted at the same tension in 2016, even while publishing one of the more influential mainstream defenses of Agile. The article praised Agile for improving success rates, quality, speed to market, motivation, and productivity in many software contexts, yet the accompanying PDF also acknowledged that some executives associate Agile with anarchy, while others interpret it as “doing what I say, only faster,” and that leaders often undermine Agile because they do not understand where it works and where it fails. That caveat should have been printed in large type above every transformation contract, because the difference between adaptive engineering and executive laziness is the difference between a good surgeon changing tactics during an operation and a drunk contractor changing the blueprint while the roof is already falling in. Agile works best where problems can be modularized, feedback is rapid, users can be engaged, and teams have genuine authority, while many corporate Agile deployments are imposed on large, dependency-heavy, politically constrained organizations where the real blockers sit above the team level. In those environments, Agile becomes a decorative language for chaos, because executives can call requirements “emergent,” priorities “adaptive,” scope creep “learning,” and lack of strategy “customer discovery.”
The real scandal therefore sits higher than the sprint board. Agile did not mainly corrupt engineering because engineers suddenly forgot planning, architecture, testing, documentation, and systems thinking, although some did absorb a dangerous adolescent allergy to anything resembling discipline. Agile corrupted organizations because it offered senior leadership a flattering story: you no longer need to define the destination with painful clarity, because empowered teams will discover it through iteration, and you no longer need to resolve conflicts early, because the process will surface learning, and you no longer need to protect focus, because velocity charts will reveal capacity, and you no longer need to understand the product, because the Product Owner will convert executive confusion into user stories. The cargo-cult version therefore spreads fastest in companies where nobody wants ownership for the big questions, while everyone wants visible evidence of modernity, collaboration, and movement. A calendar full of stand-ups, retrospectives, sprint reviews, planning poker, backlog refinement, dependency mapping, quarterly planning, and transformation check-ins creates the satisfying noise of progress, especially for organizations that measure activity more easily than outcomes. The machine rewards the person who updates the board, attends the ceremony, repeats the vocabulary, and survives the process, while the person who asks whether the whole initiative makes architectural, economic, or customer sense becomes the difficult one.
268% Higher Failure Rates for Agile Software Projects, Study Finds | Engprax
The Agile Manifesto has existed for over 21 years now, yet there remains a gap in empirical research as to the actual impact of its values on the i...
"268% Higher Failure Rates for Agile Software Projects, Study Finds | Engprax"
Agile Projects Fail 268% More Often
A recent study claimed that Agile projects fail 268% more often than other projects. I’ll explore how misinterpretations of the Agile Manifesto w...
"Agile Projects Fail 268% More Often"
The Pragmatic Engineer
How Big Tech Runs Tech Projects and the Curious Absence of Scrum
A survey of how tech projects run across the industry highlights Scrum being absent from Big Tech. Why is this, and are there takeaways others shou...
"How Big Tech Runs Tech Projects and the Curious Absence of Scrum - The Pragmatic Engineer"
Harvard Business Review
Embracing Agile
Over the past 25 to 30 years, agile innovation methods have greatly increased success rates in software development, improved quality and speed to ...
"Embracing Agile"
