Agile emerged in 2001 as a response to documented problems with heavyweight, undisciplined process. Its founders were careful about what they said and deliberate about what they did not say. What spread under the Agile label in the years that followed was not always as careful, and one strain of it has become common enough and influential enough to deserve direct examination. The history behind that drift is covered in detail in Agile: Origins, Interpretations, and Drift. This piece takes the next step.

The Posture, Named

The anti-process pose (also referred to herein as the anti-process posture) appears in several variants, but its core claims are usually some combination of the following:

• Requirements, design, documentation, and verification are overhead. 
• Code and continuous delivery are sufficient.
• Documents guard against nothing.
• If the software works, the code is the record.
• If something needs to change, change the code.

Notice that none of these views derive from the Agile Manifesto, nor its 12 principles.  Some may argue that it follows from the Manifesto’s emphasis on simplicity, but that reading doesn’t hold up to scrutiny.  The anti-process pose is one common manifestation of “false Agility” – approaches that claim to be Agile, despite retaining only the most superficial trappings.  Other forms of false Agility will not be discussed here.

The position is often defended by senior technical leaders and experienced developers whose confidence comes from software environments where rapid correction obscured the trade-offs: readily updateable systems where rapid deployment cycles and post-release correction are a normal part of the operating model. But the public record over decades suggests that this way of thinking gets too much leeway.

At most, the posture may be tolerable in experimental software (ideation work), disposable software (prototypes and proof-of-concept), or systems where being wrong carries very little consequence (such as non-interactive websites and entertainment apps). Outside of those narrow categories, it is risky and probably costly to treat architecture, documentation, or up-front thinking as optional. Software intended for constant evolution should be designed for that evolution.  Software intended to survive technical hand-offs should have descriptive documents that help the new custodians understand not only what the software does, but also why critical choices were made.  The cost of omitting these foundations may arrive late and land quietly. There is a cost, but those with no measured results to compare against may never notice it.

 No book I'm aware of makes a rigorous case for abandoning requirements, design, and verification. There is no citable body of argument that examines the engineering consequences and concludes that these things are unnecessary. What exists instead is a diffuse pattern of categorical assertion, stated in conference talks, LinkedIn posts, and team meetings by people whose authority rests less on measured outcomes than on intuition, anecdotal success, and the social weight of seniority. The posture spreads not through reasoning but through permission. Credible people said it first. Others accepted it as true because it confirmed what they already wanted to believe. The permission structure became self-sustaining.

Those who absorbed it in good faith were often developers who had only ever seen process as overhead. They had never worked in an environment where discipline was applied judiciously, with visible benefit. They are the intended audience of this piece. They recognize that something is not quite right, but have not been given a clear assessment of what is missing, why it is important, and what to do about it. The argument that follows is addressed to them.

What the Evidence Actually Shows

Agile does have a legitimate home ground. Barry Boehm and Richard Turner identified the conditions under which Agile methods are genuinely well suited: small teams, low criticality, high requirements dynamism, highly skilled practitioners, and a collaborative culture. The posture being examined here operates as though every project shares that home ground. Most do not.

The productivity claim deserves honest examination, because it is the most frequently cited justification for the anti-process posture. If Agile methods genuinely and consistently deliver higher productivity and better quality, the argument for discipline becomes harder to make. Unfortunately, the best evidence does not support that conclusion. It suggests something narrower: Agile can work well under specific conditions, but the broader claims made on its behalf have relied too heavily on anecdote and too lightly on rigorous proof.

A 2014 academic study found evidence of higher productivity under Agile methods, but with significant dispersion. The variance across teams was large enough that the average claim is unreliable as a general prediction. Some teams did substantially better than others. High variance is exactly what you would expect from a method that depends heavily on team discipline and self-organization.  This is precisely what the anti-process posture undermines.

A systematic review by Dybå and Dingsøyr, published in 2008, examined nearly 2,000 studies on Agile software development results. Only thirty-six met the criteria for methodological rigor. Let me rephrase that: 98.2% of the 2000 studies of Agile they found lacked the rigor needed to be considered reliable. The early evidence was mainly practitioner success anecdotes, not controlled studies. The reviewers called for stronger empirical work. That work has since accumulated, and it has not produced the extreme positive results the pro-Agile community believes in.

A 2025 systematic review concluded that "empirical evidence substantiating Agile superiority claims remains sparse." That is not a fringe position. It is the current state of the research literature, stated plainly.

A 2020 study of 617 software projects found Agile more successful than traditional methods only “to some extent.” However, its strongest pro-Agile findings came from broader respondent-rated success categories. On the harder project-management data the study collected, Agile projects performed worse against both budget and schedule baselines, with projects labeled “Waterfall” showing a 52.78 percentage-point advantage on budget variance and an 8.75 percentage-point advantage on schedule variance.  So, Agile felt better, but performed worse quantitatively.

The Standish Group CHAOS reports (summarized by Grokipedia), which have been the most widely cited source for Agile success rate claims, have produced numbers that vary enough across editions and interpretations to make them unreliable as evidence. Claimed Agile success rates of 42% versus 26%, or 42% versus 13%, or "three times more often" appear in different sources citing ostensibly the same data. The instability of those results does not justify the claims built on them.

The 2024 DORA State of DevOps Report is one of the largest ongoing industry studies, drawing on responses from approximately thirty-nine thousand practitioners. It found that documentation quality is a consistent, repeated predictor of high team performance. It also found that AI-assisted development increases code quality and documentation quality, but decreases delivery stability. Even the tooling argument cuts both ways.

The honest summary is that there is some signal in the productivity data, but it is weak and inconsistent. The evidence does not support the confidence with which the claims are made. When a method is credited with gains that it does not consistently produce, it becomes easier to see how some teams might try to recover the promised speed by stripping away the disciplines that seemed to slow them down. That may help explain the appeal of the anti-process mindset. It does not justify it.

What the Pose Actually Defers

Requirements don’t disappear because they haven’t been written down. They reappear as arguments during implementation, or ambiguity during verification.  Questions surface, often when the original intent has faded, the people who held it may have moved on, and the cost of reconstructing shared understanding is higher than it would have been to capture it once at the start. What looked like saved time at the beginning becomes argument, rework, and misdirected effort later.

Architecture does not disappear when no one designs it deliberately. It emerges from the accumulation of local decisions, each reasonable in its own context, none of them made with visibility into the whole. Integration is where those decisions meet, and it is often where the bill arrives. Systems built without deliberate architecture are not without architecture. They have an architecture, but it was never intended, never examined, and frequently cannot be explained by anyone on the team.

Documentation does not become less useful when teams stop writing it. The knowledge it would have captured remains distributed across the heads of the people who built the system. When those people leave, and they do leave, that knowledge leaves with them. The cost of reconstruction falls on whoever inherits the work, at a point when the original context is hardest to recover.

Verification does not diminish in value when it is treated as optional. It is deferred to the end of the project, where it becomes the first serious examination of whether the system is coherent, consistent, and defensible. Defects found there are the most expensive to correct. Rework at that stage costs more, disrupts more, and arrives when schedule pressure is highest. Earlier articles in this collection have documented this pattern in detail, and the research literature is consistent on the cost curve.

The specific rebuttal to "documents guard against nothing" deserves a direct answer. Code tells you what the system does. It cannot tell you what the system was supposed to do: what requirement it was answering, what constraint it was respecting, what alternative was considered and rejected, and why. A continuous delivery pipeline verifies behavior against tests. It cannot validate behavior against requirements that were never written. Auto-generated API specifications describe what the code does at its interfaces; they do not capture intent, rationale, or trade-offs. The gap between verification and validation, between "does it do what the tests expect" and "does it do what it should", is not a tooling problem. That gap exists because the practices that would have closed it were discarded for the illusion of productivity.

If the anti-process move is meant to recover speed, it fails on its own terms. It trades visible early effort for less visible and more expensive later effort. It does not remove complexity. It changes when the bill arrives, who pays it, and how hard it is to understand once it does. Part of the value of requirements, design, and verification is that they force the work to be examined more than once, from more than one viewpoint. That repetition is not waste. Later passes are most often faster than the first because the basic path has already been established, and the repetition is one of the ways contradictions, omissions, and weak assumptions are exposed before they become expensive.

This connects directly to a point made in an earlier article in this collection: the anti-process posture is the most concentrated example of a lesson that traveled beyond the domains where it is workable. It is well-adapted to environments where the cost of being wrong is small and arrives late, where the system is observable, correctable, and non-critical. It becomes dangerous when it crosses into environments where that cost arrives differently: where releases cannot be rolled back, where failures have physical consequences, where regulators require evidence that the system does what it claims to do, and where the people who will maintain the software in ten years are not the people who built it today.

Boehm and Turner named this problem precisely in Balancing Agility and Discipline (2003), two years after the Manifesto. They mapped the conditions that define a method's home ground across five dimensions: personnel expertise, project criticality, requirements dynamism, project size, and organizational culture. They concluded that Agile methods fit some combinations of those conditions better, while traditional plan-driven approaches fit others better. Neither dominates everywhere. Operating outside your method's home ground does not make the method wrong; it makes it misapplied. Put more directly, Agile does not map well to every environment.

The manageability benefit that Agile genuinely offers, knowing earlier where the work stands, making decisions based on visible progress rather than optimism, depends entirely on honest estimation and transparent tracking. In practice, velocity numbers that reflect what was committed rather than what was learned, backlogs that are perpetually groomed without ever converging, and the absence of any serious long-range estimation discipline mean that many teams practicing iterative development have no more accurate a picture of completion than they would from a schedule built on guesses. The ceremony of Agile is present. The visibility is not.

What Disciplined Iteration Actually Looks Like

The real divide in software development is not Agile versus waterfall. It is disciplined iteration versus undisciplined improvisation. Disciplined iteration addresses requirements, design, documentation, and verification at appropriate scale within each iteration.  It does not defer the disciplined practices to a later time that never arrives. It uses iteration's genuine strengths, including shorter feedback loops, earlier course correction, and closer customer involvement, without using them as reasons to skip the thinking that makes those feedback loops meaningful.

Several practical frameworks already embody this. DSDM, discussed in Agile: Origins, Interpretations, and Drift, is explicitly tailorable across the project lifecycle while maintaining governance structure within iterations.  This is a combination that has made it workable in regulated and defense environments where Scrum's governance silence would be a liability. Disciplined Agile Delivery combines elements of Scrum, XP, and RUP without abandoning architecture or documentation. The Team Software Process provides team-level discipline with measured data, and was among the strongest performers in the most rigorous contemporaneous assessment of software process methods.

That assessment deserves specific mention. The 2004 Cyberpartnership study was a government-sponsored evaluation published by the National Cyber Security Summit Task Force, with contributions from the Software Engineering Institute, Praxis Critical Systems, SRI International, and others. The study examined development processes for their measurable contribution to software security and quality. It was published in March 2004, three years after the Agile Manifesto, when Agile was beginning its commercial rise. Only two processes showed consistent measurable benefit in both dimensions: the Team Software Process and Correctness by Construction. Both are design-forward methods. Both require explicit up-front thinking about requirements, structure, and behavior. While organizations practicing Agile methods were included in the study, they did not distinguish themselves on the dimensions the study was measuring.

The arc from that 2004 study to the NIST Secure Software Development Framework, initially published in 2022, is a coherent thread. The NIST SSDF organizes secure software development into four practice groups, each of which assumes deliberate process across requirements, design, coding, testing, and deployment. It is widely adopted as a baseline in regulated industry and government contracting – backed by Executive Order. The profession's formal guidance has been pointing in the same direction for decades: deliberate process, early design thinking, documentation that serves the work, verification tied to explicit obligations.

Where Agile is a good fit, it can genuinely support responsiveness to change, iterative learning, customer proximity, and visible progress. None of that precludes requirements, architecture, or evidence-based verification. Nor does disciplined iterative practice imply the rigidity that sent teams running toward Agile in the first place. The synthesis exists. It has existed for some time. It is practiced in organizations that recognize its value.