Predictive or adaptive approach: waterfall, agile, and what agile was meant to be

Waterfall or agile: the question comes up as soon as you have software built. It is presented as a choice between two project management methods. The real dividing line lies elsewhere. It separates two ways of dealing with what you do not know yet: predicting it, or adapting to it.

A predictive approach decides in advance what will be built, and when. An adaptive approach decides as it goes, based on what it learns. And many practices that carry the name agile today are still predicting, by other means.

The predictive approach: the plan comes first

The waterfall model and the V-model share one principle. The stages follow one another, from requirements through to operations, and each one starts from the output of the one before. The plan is fixed at the start. Testing comes after the build.

This model has a history, and it begins with a warning. In 1970, Winston Royce, an engineer at TRW, published a paper in which he drew this sequence of stages. Just below it, he wrote: “I believe in this concept, but the implementation described above is risky and invites failure.”

He explains why. The testing phase, placed at the end, is the first point at which the system’s actual behaviour can be observed. If that behaviour does not meet the constraints, the design has to be revisited. Development then goes back to where it started, and, he writes, you can expect up to a 100% overrun in schedule or costs.

Yet Royce considered the approach sound, on one condition: adding five steps to it. Among them, doing the job twice, with the first version serving as a simulation of the second. And involving the customer, formally and continuously.

Craig Larman and Victor Basili traced what happened next. The US Department of Defense standard DOD-STD-2167 required a strict, document-driven, single-pass waterfall model. In the late 1980s, the Department of Defense experienced significant failures in its software acquisitions. Nearly ten years later, the standard’s main author said he regretted writing it: he had not known about iterative development at the time, and he would have strongly recommended it. In December 1994, MIL-STD-498 replaced the revised version, DOD-STD-2167A. It describes development in several successive builds, each of which implements part of the planned capabilities.

A predictive approach still suits a need that will not change. Work you repeat the same way every time becomes predictable. Software, by contrast, is always built for the first time.

What agile was meant to be

In February 2001, seventeen specialists in iterative methods met in Utah. The result was the Manifesto for Agile Software Development. Its title says what it is about: software development, not project management.

Its four values fit in four lines. One of them: “Responding to change over following a plan”. Two of its principles point the same way: “Welcome changing requirements, even late in development” and “Working software is the primary measure of progress”.

In this text, agile is not a method. It is an approach: deliver software that works, see what it achieves, and change direction when what you learn calls for it.

When agile still predicts

A good share of what is practised under that name today brings prediction back in.

Story points. Ron Jeffries, one of the creators of Extreme Programming, tells how they came about. His team estimated in “ideal days”, which stakeholders read as calendar days. To clear up the confusion, the team renamed them “points”. In 2019, he wrote: “I like to say that I may have invented story points, and if I did, I’m sorry now.”

Velocity. Many teams estimate each item in story points, measure how many points they complete per iteration, and work out a date from that. Vasco Duarte points out the flaw in this mechanism: as the team understands the work better, it re-estimates what is left, and the average used for forecasting keeps moving.

Scaling frameworks. In SAFe, teams get together every 8 to 12 weeks to plan the next period as a group. Among the outputs of that session, the SAFe documentation lists a board showing feature delivery dates and their dependencies.

Martin Fowler, one of the signatories of the Manifesto, named this drift in 2018: “faux-agile: agile that’s just the name, but none of the practices and values in place”. The same year, Jeffries also spoke of “Faux Agile”.

Counting instead of estimating: more honest, still predictive

Some teams have stopped estimating. Duarte proposes slicing the work into items small enough to look alike, counting how many are finished each week, and extending that pace to forecast what comes next. Allen Holub, who advocates the same method, talks about projections based on real measurements. The word belongs to this school.

It is more honest than a guess. But it is still a prediction. A guess about the future has been swapped for an extrapolation from the past.

The question has not changed: how fast will we go, and when will we be done?

The adaptive approach: no longer depending on prediction

An adaptive approach does not ask that question. It asks a different one: what is the most useful thing to do now? And it answers with what is known at that moment. Not with what was imagined on the day of the quote.

Dave Farley is blunter in his video “How To Estimate Software Development Time”: he does not believe in estimates, and says we should not either.

Frédéric Leguédois devotes a module of his training course “Un retour à l’essence de l’Agilité” (in French) to this shift: “Passer de Scrum à un fonctionnement sans projection” (moving from Scrum to working without projection; our translation). In it, he presents models based on flow, adaptability and the absence of predictive planning.

Adaptive does not mean nothing is predicted. The approach predicts what is predictable: the monthly budget and the development days per month. It does not try to predict the unpredictable: what your users will do with a feature before they have it in their hands.

There is a reason for drawing the line there. When Microsoft measures the effect of its ideas through controlled experiments, only one in three improves the target metric. One third has no effect, one third makes it worse (Kohavi and Thomke, Harvard Business Review, 2017). Nobody knows in advance which ones. You find out through use. An idea can also be tested before anything is built: that is what an MVP is for.

What this means for custom software

With a predictive approach, the feature list is fixed at the start, along with the price and the date. Yet the list is written before the software exists, on the day you know least about how your teams will use it. Every discovery made along the way becomes a change order. Every change order widens the gap with the quote. Dave Farley explains it in his video “Fighting User Requirements That CONSTANTLY Change”: developing software means learning, as you go, what it needs to do. Writing better requirements is not enough.

Our agile development approach starts from the other end. What is fixed is the budget and the problem to solve. What stays flexible is the scope, that is, the features that address the problem.

We develop your custom application on a fixed budget, invoiced at the end of each month for the work done. It is usable within a month. Usable does not mean finished: your teams use it from the first month, and that use decides what we develop the following month.

It is a fixed price, but not a fixed-scope one. Who carries the risk when requirements change, in each model: that is the subject of our article on fixed price and time and materials. And why a price set by adding up estimates so often overruns: that is the subject of our article on budget overruns.

Further reading

Our guide traces the history of the waterfall model in detail, along with what the creators of agile say about what it has become.

Do you need software built, or do you have a tool that no longer keeps up with your business? Shall we talk?

Sources

• W. W. Royce, “Managing the Development of Large Software Systems”, Proceedings of IEEE WESCON, August 1970, pp. 1-9: figure 2 and the paragraph after it (an approach that is “risky and invites failure”, testing at the end of the cycle, overrun of up to 100%); steps 3 (“Do it twice”) and 5 (“Involve the customer”); summary. Copy of the paper.
• C. Larman and V. R. Basili, “Iterative and Incremental Development: A Brief History”, IEEE Computer, 36(6), June 2003, pp. 47-56: sections “The Eighties” (DOD-STD-2167, failures of the late 1980s, its main author’s regrets) and “1990 to the present” (MIL-STD-498, December 1994); the February 2001 meeting in Utah.
• Manifesto for Agile Software Development and its twelve principles, 2001.
• R. Jeffries, “Story Points Revisited”, ronjeffries.com, 23 May 2019.
• R. Jeffries, “Developers Should Abandon Agile”, ronjeffries.com, 10 May 2018.
• M. Fowler, “The State of Agile Software in 2018”, martinfowler.com, 25 August 2018.
• Scaled Agile, “PI Planning”, SAFe Framework (8-to-12-week cadence; board showing feature delivery dates and dependencies).
• V. Duarte, NoEstimates: How to Measure Project Progress Without Estimating, v1.21, Oikosofy, 2015: ch. 2 (velocity and re-estimation), ch. 5 (counting finished items).
• A. Holub, “NoEstimates, An Introduction”, holub.com (“use projections based on real measurements”).
• F. Leguédois, training course “Un retour à l’essence de l’Agilité”, Moovence, in French: programme, module 4 “Passer de Scrum à un fonctionnement sans projection”.
• D. Farley, “How To Estimate Software Development Time”, video (“I don’t really believe in estimates and neither should you”).
• D. Farley, “Fighting User Requirements That CONSTANTLY Change”, video.
• R. Kohavi and S. Thomke, “The Surprising Power of Online Experiments”, Harvard Business Review, September-October 2017.