Waterfall and agile disagree about how much to build before checking it. Neither asks which direction to plan.
A Series B company with 45 engineers ran Scrum properly. Two-week sprints, stable velocity, demos every other Friday. Its largest customer, $1.8 million a year, had renewed the previous October with a new clause: a SOC 2 Type II report by the next renewal date, 15 October.
In January somebody wrote a backlog item called "SOC 2 controls" and gave it a value rank. That sentence contains the whole failure. A contractual obligation with a date on it went into a queue that cannot see dates, to compete on customer value against feature work. It lost every sprint, as it should have: a compliance report is worth nothing to any customer except the one already paying. The ranking was correct. The decision to rank it at all was the mistake.
In June the customer's security questionnaire arrived and somebody finally called an audit firm. A Type II report says the controls actually ran, over a window of usually six months, and the report takes four to six weeks to issue after the window closes. The audit firm books eight to ten weeks out. Counted backwards from 15 October: engage the auditor by November of the previous year, have the controls running by February, close the window by the end of August. The item was late the day it was written. It then sat at position 61 for five months while every ceremony in the process ran correctly around it.
Counted forward from June, the earliest report date was the following April. The customer stayed, at a price: a bridge Type I report, which checks a point in time rather than a period, a 15% discount on the renewal year, a penalty clause if the Type II slipped again. The discount cost $270,000. Two senior engineers came off the roadmap for a quarter, roughly $165,000 more. The roadmap slip is in neither number.
The retrospective asked whether the team should have been less agile about compliance, more waterfall. The question is fifty years old and both answers are wrong.
What Waterfall and Agile Actually Disagree About
The war's founding document does not say what either side thinks it says. Winston Royce's 1970 paper contains the famous diagram of requirements flowing down through design, code, and test. Two pages later it contains his verdict on that diagram: "the implementation described above is risky and invites failure." Royce recommended building everything twice and iterating between phases. The word "waterfall" appears nowhere in the paper. Later authors pinned it on him, citing the diagram without the warning.
The caricature became doctrine anyway. In 1985 the US Department of Defense published DOD-STD-2167, which wrote development in one pass, with a document sign-off between each phase, into defence contracts. Nine years later MIL-STD-498 walked it back and let teams deliver in steps. Craig Larman and Victor Basili, reconstructing the history in IEEE Computer in 2003, report the older standard's principal author regretting the damage. They also show that delivering in steps was not a 2001 invention: Project Mercury's software, at the end of the 1950s, was built in half-day iterations with tests written before the code.
What the seventeen people at Snowbird fixed in 2001 was how much work gets committed before anyone checks it. Waterfall commits a year of work before the first user sees anything, so a wrong assumption survives the whole year. Agile delivers a working slice every two weeks, so a wrong assumption survives two weeks. Smaller pieces make being wrong cheaper. That correction was real.
Everything since has been an argument about the size of the pieces. Waterfall plans forward from requirements in one long pass. Scrum plans forward from a backlog, two weeks at a time. Both start at today and ask what to do next. Certification bodies, coaches, and transformation programmes built an industry on choosing between them, and the choice cannot save a dated commitment, because dated commitments die of something the war never touched: which direction the plan runs.
A Backlog Is a List of Wants
Ordering a backlog by value rests on two assumptions nobody states. Every item can start whenever the team gets to it, and how long an item takes depends on how hard the team works on it. Both are true for work the team owns, and there value ordering is the right tool.
An item with an outside clock breaks both assumptions, and putting it in the backlog anyway files an obligation as if it were a want. A ranked list of wants is not a plan, however carefully it is groomed. A plan for a dated obligation states what must be true and by when. The backlog never claimed to do that. The company behaved as if it did, which is the same confusion that lets executives present a list of goals and call it a strategy. Naming the future you want is not a method for reaching it.
For work on an outside clock, urgency has nothing to do with value. It is the commitment date, minus the weeks to issue the report, minus the window, minus the booking lead time. That subtraction is called a backward pass, and nothing in Scrum performs it. Sprint planning asks what is most valuable next, and the correct answer to that question was, every single sprint, not the audit. The methodology answered the question it was asked. It was asked the wrong question for ten months.
A Gantt chart would have failed differently, not better. Forward-built schedules hold the tasks somebody thought to sequence, and they miss conditions somebody else owns exactly as a backlog does. Neither methodology contains the backward question, because both answer "how to build", and this was a failure of "what must be true".
Clocks You Do Not Own
Every delivery commitment of any size contains work whose length is set by somebody outside the building. Audit observation windows. Vendor procurement cycles. Regulator queues. Certification labs. A customer's change freeze. A data centre's notice period. These have three things in common. Adding engineers does nothing to them. They can almost always run alongside the build. And starting them late is what costs, because a fixed-length clock started past its latest start date pushes the end date back day for day.
Here is the same report under the two orderings.
| Item | Sorted by value | Sorted by latest start |
|---|---|---|
| Auditor engaged | June | November, previous year |
| Controls operating | September | February |
| Observation window | September to March | February to August |
| Report delivered | April, six months late | 15 October, on the date |
| Renewal discount | $270,000 | $0 |
| Unplanned engineering | Two seniors for a quarter, $165,000 | Scheduled, on the roadmap |
| Cost of the ordering | $435,000 plus the roadmap slip | $0 |
The work was identical in both columns. The controls cost the same to build, the audit cost the same to run. The only variable was the question that ordered the work. Value ordering stayed correct for the other sixty items on that backlog. For the one item on somebody else's clock it was the wrong tool, and the methodology gives no way to tell which items it is wrong for. That is a defect in the design, not an edge case. A planning system that cannot tell a want from a dated obligation will file obligations as wants every time, and a customer will discover it each time.
Two Separate Choices
How a team plans and how it delivers are separate choices, and the methodology war spent five decades treating them as one. Waterfall is forward planning with delivery in one long pass. Most agile practice is forward planning with delivery in small pieces. The industry changed how it delivers, kept planning in the same direction, and called the change progress.
Backwards planning is older than software. The US Navy's Special Projects Office built PERT for the Polaris programme in 1958, and its backward pass computed the latest start date for every activity in the network as a matter of routine. The software industry declined to inherit it.
The combination that holds a dated commitment is planning backwards and delivering in small pieces. Fix the outcome as a sentence an outsider could check. Ask what has to be true for it, which surfaces the conditions and their clocks. Run the backward pass, which hands every item a latest start date and separates the work that can wait from the work that is quietly already late. Start the outside clocks immediately, because they run in parallel and cost nothing to start. Then deliver the engineering inside that frame in pieces as small as the team likes. Amazon has run both halves together for twenty years: the press release and FAQ are written backwards from the outcome before code exists, and small teams then ship continuously. Nothing in the Agile Manifesto forbids any of this. The manifesto says how often to deliver and nothing about which direction to plan.
The one boundary is discovery. Backwards planning needs an outcome specific enough to plan back from, and genuine research does not have one; forcing a dependency graph onto a search produces a confident plan that is wrong. But a company with a signed renewal clause and a dated report obligation is not searching. It knows exactly what it owes, and calling that work discovery is an excuse.
One Question at the Next Planning Session
Agile won its argument with waterfall on the merits, and the miss rate on dated commitments did not move, because dated commitments do not die of building too much at once. They die of planning in the wrong direction, and both methods plan forward.
The company with the audit executed agile precisely for five months, and the precision is what hid the failure. In January it held a signed obligation, a known audit mechanism, and ten months of room. It chose to file the obligation in a queue built for wants, and every correctly run ceremony after that choice was effort spent in the wrong direction.
The test costs nothing. Take every item that touches a dated commitment, mark the ones that run on a clock the team does not own, and count backwards to the latest date each can start. Most teams find at least one date that has already passed, attached to an item sitting mid-backlog, correctly ranked by value and dead.
Two-week sprints fit inside a plan drawn backwards from a date. No sprint, at any velocity, gets through six months of somebody else's clock in four.