A senior technical leader, whose career had been built in software product development, argued recently that code and continuous delivery are sufficient; that documents guard against nothing; that knowledge transfer happens when you push a change to a product; that architectural consistency, if it matters at all, gets measured automatically. He didn’t intend for that concept to be provocative. He meant it. And within the domain he was describing (software products, updateable systems, environments built around rapid deployment and post-release correction) there are plenty of people who hold that worldview. 

The problems start when those ideas start moving out of the low-consequence realm that was being described.

I have written several articles about what stronger software foundations look like, and why they matter. Most of that has been constructive: what good requirements discipline produces, what strong architecture enables, what careful verification actually measures, why certain practices persist in high-assurance work even when they are not fashionable. The argument has been, for the most part, an affirmative one.

This piece is different. This time there is a specific resistance worth examining carefully. It travels under the Agile label. It unjustly borrows Agile's credibility. And in many environments, it has quietly discarded the discipline that gave Agile its legitimate strengths. Before addressing that, it is worth being precise about what Agile actually is, because the word has accumulated enough contradictory meaning that almost any position can be argued in its name.

The Process They Rejected Was Real

Start with the honest admission: bad process exists, and it is genuinely wasteful.

Most developers who have worked in a medium-to-large organization have seen it. Standards that were never viewed again once they were agreed on. Requirements documents that were never read after they were filed. Design reviews that checked a box with only a cursory examination of the design. Traceability matrices that did not seem to serve any engineering purpose. Test plans that ran through the motions of coverage while only haphazardly looking at edge cases and boundaries. Process bloat is real, and it is not a minor irritant. It consumes time and budget, produces artifacts that provide false confidence, and leaves teams with the worst of both worlds — the overhead of formal process without the benefit of substantive discipline.

For developers who spent their formative years in those environments, the conclusion that process itself was the problem is understandable. It’s the wrong conclusion, but it is an understandable take-away. Contempt for process discipline is often really contempt for bad process, misdirected at the idea of process itself.

This is also where anti-process sentiment got its initial credibility. In many cases, it was arrived at by capable developers who looked at the dysfunction around them, found a permission structure that felt like liberation, and stopped asking what should replace the thing they had rejected.

Where Agile Actually Came From

By the late 1980s, iterative development was already a serious engineering idea. Barry Boehm's Spiral Model, published in 1988, described a risk-driven iterative approach that explicitly rejected the notion of a single, complete design phase followed by implementation. In that same year, Ivar Jacobson developed the first incarnation of “Unified Process” encompassed within his Objectory Process; and Sally Shlaer and Stephen Mellor’s "Object Oriented Analysis & Recursive Design” concept was born. The big idea that software development should cycle through planning, risk analysis, engineering, and evaluation — repeatedly, with each pass informed by what the previous one revealed — was in the literature more than a decade before the Agile Manifesto was written.

The rapid prototyping era of the 1990s added a practical complication that helped shape what Agile became. Prototyping had become common practice, and with it came a documented, named management failure: the tendency to keep prototype code rather than discard it. Steve McConnell identified "keeping a throwaway prototype" as a classic software development mistake in Rapid Development (1996), noting that managers frequently refused to discard prototype code because it appeared to work, despite having been built without the discipline needed for production quality. Frederick Brooks had named the same instinct two decades earlier in The Mythical Man-Month (1975): "plan to throw one away; you will anyhow." Evolutionary prototyping, refining a prototype rather than replacing it, was already an established alternative before 2001. What Agile contributed was a manifesto, a name, and a community of practice organized around the approach.

The Snowbird meeting in February 2001 brought together seventeen practitioners representing a range of iterative methods ( XP, Scrum, DSDM, Crystal, FDD, and others ) to articulate what they held in common. The result was a document that has since been interpreted in almost every direction imaginable, so it is worth returning to what it actually said.

The Manifesto's four value pairs are carefully constructed. It does not say no process. It says "individuals and interactions over processes and tools," meaning that rigid process adherence should not substitute for human judgment. It does not say no documentation. It says "working software over comprehensive documentation," meaning that documentation whose primary purpose is its own existence is waste. It does not say no planning. It says "responding to change over following a plan," meaning that a plan is a tool, not a commitment to be defended regardless of what is learned. These were not radical propositions. They were corrections to specific pathologies that the signatories had observed in practice.

The claim that "documents guard against nothing" is not in the Manifesto. The claim that code alone is sufficient for knowledge transfer is not in the Manifesto. The claim that architectural consistency should be an emergent property measured automatically rather than a design concern addressed deliberately is not in the Manifesto. Those positions arrived later, from people who claimed that it was all part of being Agile.

A Map of the Flavors

One reason the word "Agile" generates so much confused argument is that it covers methods that differ substantially in their technical discipline. Treating them as interchangeable makes the conversation almost impossible to resolve.

XP (Extreme Programming) is the most technically prescriptive of the original Agile methods. Test-driven development, pair programming, continuous refactoring, and continuous integration are all practices that require more deliberate thinking about behavior and structure before coding begins, not less. Bob Martin, one of the Manifesto's signatories, has said that XP is the closest thing to what the Manifesto's original intent described: a technically demanding approach that earns its agility through discipline, not by substituting motion for thought.

Scrum is a project management framework, not a technical methodology. Ken Schwaber and Jeff Sutherland designed it to provide a cadence and a set of roles and ceremonies for iterative delivery. Scrum does not specify how engineering work is done. It does not prescribe how requirements are defined, how design decisions are made, or how verification is conducted. Those choices are left entirely to the team. Scrum became the dominant Agile flavor in the US market, and in doing so, it became the primary vehicle for whatever engineering habits (or non-habits) a team brought with it.

DSDM (Dynamic Systems Development Method) represents a different branch of the original Agile tree. Created in 1994 by a consortium of UK-based practitioners and organizations, DSDM is explicitly process-centric. It uses timeboxing (another term for Sprints) and MoSCoW prioritization to manage scope against fixed time and budget constraints, and it defines roles, governance structures, and lifecycle phases more formally than most Agile frameworks. Among the original Snowbird methods, DSDM comes closest to RUP in structural rigor. It has found a home in UK and European practice, and has been adopted in regulated and government-contract environments where governance requirements make its structure attractive — defense contracting is a documented example. It was largely bypassed in the US market, where Scrum became dominant. That was a choice, not an inevitability.  It is a point of interest that SCRUM and DSDM can be used together, as they address two differing levels of Agile application.

TDD and BDD are practices rather than full methodologies. Test-driven development in particular requires explicit, disciplined thinking about expected behavior before a line of implementation code is written.

SAFe, LeSS, and DAD are scaling frameworks developed when Scrum proved insufficient at enterprise scale. Their common characteristic is that they reintroduce architecture review, program-level planning, and cross-team coordination — precisely the overhead that "pure" Agile was supposed to make unnecessary. Their existence is an acknowledgment that the discipline did not disappear when teams adopted lightweight Scrum. It was deferred, and it came back at scale, more expensive than it would have been if it had been addressed from the start.

Agile Modeling and Model-Driven Engineering are rarely discussed in mainstream Agile circles, which reflects a broader pattern examined in an earlier article in this collection: the same cultural forces that made lightweight, iteration-forward methods more attractive in software product environments also made modeling disciplines feel like overhead. That dismissal does not have a sound engineering basis, and many teams would benefit from even a modest engagement with modeling practices without needing to adopt a full model-driven approach.

The pattern across these flavors is consistent: the methods that stayed closest to their technical roots ( XP, DSDM, and TDD ) retained the discipline. The method that spread furthest, vanilla Scrum as commonly practiced, shed it. The scaling frameworks that followed were attempts to recover what had been lost. That pattern is worth holding in mind when evaluating claims made under the Agile label.

What the Originators Actually Said

Given how much has been argued in the Manifesto's name, it is worth going back to what some of its authors said later, with the benefit of watching what the movement became.

Bob Martin, one of the Manifesto's signatories, wrote in Clean Agile (2019): "Some folks think that Agile is about going fast. It's not. It's never been about going fast. Agile is about knowing, as early as possible, just how screwed we are." That formulation is more useful than most of what the Agile marketing apparatus produced in its place. It is not a productivity claim. It is a visibility claim. The contribution of disciplined iterative development is not that it makes teams move faster.  It is that it makes the actual state of the work visible earlier, so that decisions can be based on something more reliable than optimism.

Martin also reflected, in a 2024 interview, that the Agile movement had been taken over by project managers and consultants who stripped out the technical discipline that the original methods required, and that this drift was at least partly a consequence of structural decisions the founding community made and later regretted. That is not a criticism from the outside. That is one of the movement's co-founders naming what happened, and saying it was not what was intended.

Martin Fowler, Kent Beck, and Alistair Cockburn, all Manifesto signatories, have each pushed back, at various points, on readings of the Manifesto that treat it as a license to skip design, documentation, or disciplined thinking about behavior. Cockburn has clarified that the documentation value statement was never meant as a prescription for zero documentation. It was a reaction to the specific pathology of documentation that exists for its own sake, not as an endorsement of operating without any shared understanding of what is being built.

The manageability argument deserves a separate note. Agile's genuine contribution, at least the one that holds up under examination, is visibility. Shorter iterations, closer customer involvement, and honest tracking of what is actually done versus what was planned all improve the organization's ability to understand where the work stands and make better decisions earlier. But the visibility benefit depends entirely on honest estimation and transparent progress tracking. Without those, what looks like visibility is something closer to illusion: a cadence of meetings, a board with cards, and a velocity number that reflects what was committed rather than what was learned. The manageability benefit does not come automatically with the ceremony. It requires the same kind of discipline the anti-process posture tends to dismiss.

There is a version of the Agile argument that I find genuinely promising, and that makes it worth describing before moving on. A former colleague of mine spent decades developing implantable cardiac defibrillators, later led the Agile initiatives at his employer, and eventually started a consultancy focused on Agile adoption in medical technology and other safety-critical domains. His definition of Agility was not a framework or a set of ceremonies, those were just tools. It was a mindset toward process itself: if something is not working, stop doing it and make the necessary adjustments as quickly as possible. In his view, process exists to serve engineering goals. If requirements, design, and verification were necessary to the outcome, and in his domain they clearly were, then a sound process included them. The discipline was in honestly evaluating whether each step was doing its job, not in defending it because it was inherited.

That framing is compatible with more than one practical approach. DSDM, discussed earlier, is actually closer to this spirit than its reputation for rigidity suggests.  Its timeboxing is fixed within an iteration, but the framework is explicitly tailorable across the project lifecycle, which makes it a reasonable fit for safety-critical work where regulatory scrutiny rewards governance structure rather than penalizing it. The mindset and the framework are not opposites.

What I will say about the mindset approach on its own is that it requires something most teams do not have: the accumulated experience to recognize when a process step is genuinely unnecessary versus when it merely appears unnecessary because its purpose is not well understood. My colleague could apply that judgment because he had spent decades in an environment where the cost of getting it wrong was unambiguous. For a developer who has only ever seen process as overhead, the same mindset becomes yet another reason to discard too much; not because the principle is wrong, but because the baseline needed to apply it honestly is missing. 

What the authors of the Agile Manifesto built was a framework for disciplined iteration.  What is now called Agile in many organizations discards much of the value of the approach: a posture that borrowed the credibility while leaving behind the obligations. In False Agility and the Anti-Process Pose, the anti-process posture gets a closer examination: what it actually claims, what the evidence shows, and what costs organizations can expect when it is misapplied.