Saying goodbye to Agile

Saying Goodbye to Agile

RIP Agile, we hardly knew ye.

And I mean that literally - because no one was ever clear on what it was.

Agile washed over our industry like a tsunami. But whenever it was questioned, a voice (perhaps emanating from a gap in the clouds?) would invariably tell us "ah, but that is not True Agile - The Manifesto sayeth naught of Daily Standups, nor Agile Coaches". Yet if one read the Agile Manifesto (2001), this wellspring of our enlightened New Era of Software, one inevitably found it didn't actually tell us much at all. At best it was a sequence of vague platitudes ("Customer collaboration over contract negotiation"), and at worst it was commercially unworkable ("Welcome changing requirements, even late in development").

So if the Agile Industry was not doing Agile Properly, and the manifesto itself was near devoid of meaning, then what exactly was it?

"A spectre is haunting Software, the spectre of Waterfall"

Agile was always defined primarily in terms of what it wasn't - and what it wasn't was Waterfall. If you were not doing Agile, you are doing Waterfall, and Waterfall Did Not Work.

Except we'd known Waterfall did not work since 1970; and Winston W. Royce laid out exactly why, recommending we instead:

• Start with a program design.
• Make a prototype of the software to gather information to refine requirements.
• Involve the customer ("the involvement should be formal, in depth, and continuing").

All of these things were later claimed as Agile innovations. In reality, they were written the year after the moon landing.

And even in that decade it was not the only work moving away from Waterfall. A 1976 paper by Bell and Thayer - which first coined the term "Waterfall" - tells us at the end of an empirical study:

The types of problems detected in requirements changed during the life of a software development project. The system developers often determined requirement deficiency only when they attempted to meet the requirements with a design.

So it's clear that iterative development was not new, and would continue to be further refined in the decades before Agile. Waterfall was not the state of the art ere The Manifesto liberated us. And no one serious doubted the effectiveness of requirements and specifications.

Spec-Driven Development

For good or for ill, the availability of cheap LLMs trained on massive programming datasets has altered the way many of us program computers, and arguably shifted the zeitgeist of software.

One unambiguously positive development that's followed is that software professionals are writing specs again. LLMs - like many of us - do not perform well with ambiguity, and specifying problems is proving to be an effective tool for generating correct code. Agile told us "Working software over comprehensive documentation". Spec-Driven Development is telling us "Comprehensive documentation creates working software". And really, LLMs or no, there is nothing new under the sun. Quoth Royce:

Until coding begins these three nouns (documentation, specification, design) denote a single thing. If the documentation is bad the design is bad. If the documentation does not yet exist there is as yet no design, only people thinking and talking about the design which if of some value, but not much.

Reading 1970 and 1976, one has to ask what 2001 really brings us. Agile was defined vaguely and marketed as solving something already solved half a century ago by serious engineers whose papers made more sense. As our field continues to change - and we hope evolve - it's time to look at things with a fresh perspective, and put Agile in the dustbin of history where it belongs.