Waterfall and Agile, Honestly

The paper universally cited as the origin of waterfall is Winston Royce’s Managing the Development of Large Software Systems, presented at IEEE WESCON in 1970.¹ The diagram on the second page is the one every undergraduate has seen: requirements, analysis, program design, coding, testing, operations, arranged in a descending staircase.

It was what engineers of my generation — I am a proud millennial — were trained to hate. Nobody taught me the crucial part. Royce drew that staircase to argue against running it once. On the same page as the diagram he wrote, in plain prose, that a single pass through the model was risky and invited failure, and he spent the rest of the paper proposing iteration, prototyping and customer feedback instead.

The profession kept the diagram and dropped the warning. It is the fate of most engineering papers.

What Royce was actually writing about was the experience of building software for spacecraft mission planning and command at TRW in the 1960s, where getting it wrong could cost the mission. His argument was that unplanned software against high-consequence hardware was ruinous, and that the way to make the planning honest was to do it more than once. Every methodology the field has produced since has contained, somewhere in the small print, the same escape clause. Royce put his on page two and was ignored for the next thirty years.

A decade later, Barry Boehm published the empirical ballast that justified the one-pass reading of Royce on cost grounds.² His 1981 book, Software Engineering Economics, drew a cost-of-change curve from project data at TRW and other large firms. The curve showed a defect caught after deployment costing up to a hundred times what the same defect cost if caught during requirements, and a 1988 paper he wrote with Philip Papaccio put the multiplier at fifty to two hundred. The ratios looked exotic at the time and they are worth restating: one dollar in requirements, fifty to two hundred in production, with a steep climb through design, coding and test between the two.

In a world where that curve was true, the ritual of long design phases, formal inspections and signed-off specifications was insurance against a cost regime in which each later stage of work was orders of magnitude more expensive than the one before it. You planned because planning was the cheapest thing you could do, and because everything after the planning was dear.

Fred Brooks had said the same thing from a different angle in The Mythical Man-Month in 1975: adding engineers to a late project made it later, and once a system was partly built the cost of changing your mind was paid twice — in rework, and in the overhead of telling everybody else you had changed it.³

A compile took hours. A deployment took a week. The fix for a bug caught in production shipped on a magnetic tape to every customer site, by courier, on a date agreed months in advance. The build was slow, the redeploy slow, the blast radius of getting it wrong carried on the back of the client. In that reality, planning was the rational step — the arithmetic made you pay for caution either way.

From inside the engine room, for engineers paid to write against the plan rather than commission it, the work looked like months of implementation against a document that could not be argued with. The spec had been signed. The signatures carried legal weight. A developer who noticed, in week eleven, that a workflow in chapter four contradicted a workflow in chapter nine had no authority to choose between them; a change request went up to a board that met on Thursdays, returned on the Friday following, and the two days in between were billed to the client. The job was to comply, not to think. Obedient work is also an expense item on someone’s balance sheet.

I did this too. Between 2010 and 2013 I planned in detail, signed eighty-page specifications and billed happily for the Thursday change-control board. Waterfall, in that period, was an expense report. The clients could not price the risk of changing their mind without a Gantt chart, and I could not run a studio without a signed number at the bottom of one. The ritual was what both sides agreed to call the thing they both feared.

Even with the build expensive and the plan comparatively cheap, the method carried a second cost that nobody priced properly. A hospital migrating its patient-admission system can specify it because it has run one for forty years; a factory can specify an MRP system because it has three already on the shop floor. A founder with an idea for a new product has never run the product. The specification waterfall asked them to sign was a specification for a thing they had never yet used. Murray in the previous chapter is the pure case — three circles and three arrows, no prior system in the world, a year of calls before the document was honest enough to build against. The extraction took the year because the artefact did not exist.

Outside the rooms where a prior artefact did exist — the hospitals, the factories, the aircraft-electrical-harness certifiers, the bank core ledgers — the arithmetic broke, and it broke quietly, over roughly two decades.

The compile got faster. The deployment got cheaper. The machine got cheaper. The customer stopped receiving shipped tapes and started refreshing a web page. By the time Sliday opened in 2009, the cost of catching a defect in production was no longer fifty to two hundred times the cost of catching it in requirements. On a Rails monolith with a CI pipeline and a one-click deploy, the cost of catching a defect in production was a Wednesday afternoon, a git revert and an apologetic email to two hundred users. The ratio had collapsed from two hundred to roughly one. The arithmetic that had justified the whole ritual of long design had been silently subsidised out of existence by the toolchain underneath it.

What replaced waterfall, outside the hospitals and the factories, was the ability to try a thing, watch it break, fix it and try it again, all inside a single afternoon. The moral vocabulary arrived later, retrofitted to the tooling. First the cost of an experiment collapsed; then a generation of writers found it obvious that running experiments was how you should build software, and wrote manifestos saying so.

The manifesto those writers signed came out of a ski resort in Utah in February 2001.⁴ Seventeen people — Kent Beck, Martin Fowler, Ward Cunningham and the rest of a small roster of consultants and authors — spent a long weekend at Snowbird and came out with four value statements, twelve principles and a name. The tooling had already made iteration possible; they named the practice that followed from it and wrote it down. The Manifesto sits online today in more or less the shape they left it.

The first Karma dashboard I shipped at Sliday was for my own studio, ran on a Friday night’s work and had a login page that accepted any password as long as it was more than four characters.

This was 2014. Sliday was five years old, the team by then about seven people across Auckland and one remote engineer in Minsk, and we were doing a bad job of remembering who had stayed late, who had saved a deadline by rewriting someone else’s broken commit on a weekend and who had quietly taken a client to lunch when a client most needed lunch. We had a Slack channel for “good work” messages, and that channel had the property most good-work channels have, which is that the same four people get mentioned and the other three go unseen. I wanted a small tool that let anyone on the team give anyone else on the team a visible token of recognition, attached to a real note and aggregated monthly so that nobody needed to keep score in their head.

I built the first version that weekend. It was ugly. It did the thing.

By the end of the following month, four of our clients had asked whether they could have one.

That was the beginning of the Karma SaaS, and also the beginning of what I now think of as our honest agile period. The product ran inside Sliday for about eighteen months before we offered it to anyone else. Between that Friday night and the first external customer sat the quieter work: adding SSO, writing the data-export endpoint an HR lead would one day ask for in a subject-access request, replacing the four-character rule with something a security review could read without wincing. The product was the same; the scaffolding was not. During those eighteen months we shipped new versions of it, on our own team’s feedback, in two-week cycles. When Karma went external in mid-2016, it kept the two-week cycle, and it kept it — with no ceremony drift, no certification, no velocity charts — for the next six years. By 2022, Karma had roughly four hundred paying teams and an annual recurring revenue of about four hundred and forty-four thousand dollars. Three and a bit engineers, a designer who also did illustration and a support writer who also did onboarding emails. That was the entire team.

I tell this story because I have spent most of the past two years listening to people announce the death of agile, and I want to go on the record: agile, practised with discipline and a founder actually present, built Karma. I have the commit history. I have the invoices. I have the quietly pleased Slack messages from HR leads in Berlin and Melbourne who now had a way to show their teams being seen. Agile did that. Not a conference talk about agile. Not a certified Scrum Master. Agile, which in this book I will define as iterate in public, with the user, in cycles short enough that you can be wrong without dying of it.

This is also the moment where I have to admit that for the multitude of client projects my team shipped in the same era, what actually happened was agile’s theatre.

One of those projects has stayed with me. A client engagement a few years into our agile period: two-week cycles, stand-ups dead on time and a Jira board that grew a second swimlane once the first had become unreadable. I remember a retrospective where a green velocity line climbed the screen and someone on the client side said it looked like we were smashing it. We were. What nobody in the room had asked — not me, not the project manager, not the lead on the client side — was whether the feature we had been smashing out for weeks was one any user had asked for. It was not. We billed hundreds of hours against it. It was all within scope. It was all invoiced. It was all rational at the time.

I am careful with the distinction, because dismissing agile’s bad cosplay is not the same as dismissing agile. The clients were not stupid and nor were we; we had all been taught that certain rituals belonged to the work, performed them, and only years later did I notice the ritual was sometimes the whole of what we were performing.

The ritual set varies by studio but the pattern does not. Four-person teams holding fifteen-minute stand-ups that became twenty-five-minute stand-ups that became where did this morning go. Story points allocated to tasks where the estimating conversation cost more engineering time than the task itself. Sprint retrospectives run on projects that had not yet seen a user. Jira boards whose velocity graphs went up and to the right in ways that would have embarrassed everyone had anyone checked whether the thing being built was what the client actually wanted. We were busy. The client was paying. Something that looked like agile was visibly happening.

I can put rough numbers on the ceremony. At our current blended rate of roughly ninety dollars an hour, a four-person team’s fortnightly ceremony — a fifteen-minute stand-up every weekday, one two-hour sprint planning and one ninety-minute retrospective — costs out like this:

10 standups × 15 min      =  2.5 hrs
sprint planning           =  2.0 hrs
retrospective             =  1.5 hrs
                          ─────────
per person per fortnight  =  6.0 hrs
× 4-person team           = 24.0 hrs
× $90 / hr                = $2,160 per sprint

Call it two thousand dollars a fortnight on ritual alone, before anyone has written a ticket. On Karma that was money well spent. On the theatre projects it was not.

I have watched this happen more than once. The quietly strong engineer — often the one who had read the Manifesto and taken it seriously — notices in round three that the retrospective has predetermined conclusions. In round four she says so, framed as a question rather than a complaint, and is told to keep her feedback constructive. By round eight she is still shipping, but the small unsolicited observations about the thing we were actually building have been absorbed inward, and nobody on the studio side is the richer for their absence.

Underneath, several of those projects were waterfall, quietly. The scope had been agreed up front; the sprints were chopping an agreed plan into two-week slices; the client was not on the vehicle at all. The cadence was the same as Karma’s. The difference was that Karma had a real user riding the scooter every fortnight, and the other projects had a progress report delivered every fortnight to a client who did not yet know what the finished car was supposed to look like.

The honest name for the ritual-without-the-ride is sprint-shaped waterfall. Across the studios I know, I think it is the majority of what was called agile between roughly 2012 and 2022.

This is not a new observation. In March 2014, thirteen years after signing the Agile Manifesto, Dave Thomas — one of the seventeen original signatories and co-author of The Pragmatic Programmer — wrote a short blog post, and gave a talk the following year at GOTO Amsterdam, arguing that Agile with a capital A had become something other than what he had signed up for.⁵ The adjective had been turned into a noun, and the noun branded, certified and sold. He named the decay inside agile from inside agile, nearly a decade before the AI wave arrived.

Agile in pure form solved the case where the founder did not yet know what they wanted and would ride successive versions of the scooter until they did. That was Karma: a fifteen-minute Monday call, a shared document the founder edited directly, a version shipped on the Friday of week two whether or not it was pretty. Nothing worshipped. Everything observed.

For a studio running sprint-shaped waterfall on a signed-off scoping document with no user in the loop, agile was an expensive costume that happened to cost two thousand dollars a fortnight to wear. The new tools leave agile standing and reveal that the costume was always being worn over the waterfall, by making it possible — for the first time — for the founder to hand over a working vehicle on day one and skip the years we used to spend extracting a specification from them.

Neither method survived contact with the next change in cost structure. Waterfall was rational when the build cost a quarter and a signed spec. Agile was rational when the build cost two-week cycles and a team on a scooter. When the founder started arriving with a working repository on a Monday morning, the two methodologies we had inherited collapsed into a single problem neither of them had ever been designed to solve: what to do with a specification that has already been written, in code, by the person whose product the specification was supposed to describe.

Waterfall did not lose to a better idea, it lost to a cheaper compiler.