Waterfall: A Recipe for Failure

Anyone can understand what Doctolib does. However, “building” Doctolib is complicated. This example clearly illustrates the challenges of business software development: producing code at scale, in a context of high uncertainty regarding user needs.

For this type of software, let’s be very clear: sequential “waterfall” methodologies do not work outside of very small projects. Waterfall projects costing several million euros simply do not work. This is not a matter of “bad luck,” nor is it even a question of skill: it stems from structural reasons.

Definition of Sequential Methodologies

Sequential methodologies are defined by the fact that the project consists of a series of non-reversible stages. Thus, the functional design is completed once and for all, and then the project moves on to the technical design, treating the functional design as a given.

These stages are as follows: scoping, drafting of requirements, request for proposals, functional design, technical design, development, acceptance testing, and deployment. The project is then complete, and the application enters the maintenance phase.

On paper, it looks wonderful. In reality, it doesn’t hold up for even two seconds.

Why the Waterfall Model Doesn’t Work

Reminder: We are talking here about business software, which is characterized by uncertainty regarding user requirements. Waterfall methodologies remain valid in other contexts.

• The main reason is the tunnel effect. What the user asks for is rarely what they actually need. This can be worked on, but ultimately, only the actual use of an application in production by real users can determine whether what was developed is useful or not. So if you set out with high hopes for a year of development without any intermediate deployment, you risk spending months solving imaginary problems and developing unnecessary features. As they use it, your users will also discover that they need another feature, one your app doesn’t offer, that will take you months to develop. What you want is regular feedback so you can adjust course as needs become apparent through actual use.

• Well, assuming you got the specifications right, your project manager now needs to take ownership of them. On projects worth several million euros, specifications frequently exceed a thousand pages. You spent time drafting this document, so you implicitly expect it to be sufficient. Unfortunately, believing that it will enable your counterparts to understand you is a fantasy. You can’t ask a document questions; you can’t ask it to rephrase anything; and this document isn’t enriched by the reader’s input. We need to be able to discuss things! And don’t even get me started on the Q&A sessions during the bidding phase; they’re no substitute for real working sessions and the collaborative process they enable.

• All right, but assuming your client has understood you perfectly, they now need to estimate the associated workload in order to provide you with a proposal. You know as well as I do that the larger the scope of the work to be estimated, the greater the margin of error in the estimate. Considering that the quote is based on a statement of requirements, that is, before the functional design phase, any estimate is akin to a game of chance, more specifically a game of Russian roulette. Given the scope of the project, the estimation error isn’t 15 or 20 percent, but rather 50 to 100 percent.

• Finally, there’s a high likelihood you’ll suffer the adverse effects of the bidding process. The game is simple: candidates for the project management role drive the price down as much as they can in the hope of landing the contract, and they do so all the more easily because they’re unaware of the complexity of your business. From this field of contenders, a winner emerges, whose sole obsession will be to remain profitable despite the risk they’ve taken. As the complexity of the business becomes apparent, the specifications become a sacred text open to interpretation: were these features actually part of the scope or not? Some requirements weren’t explicitly stated, because they were too detailed, but they’re still necessary for the system to function. So a full-blown battle over the scope of the project ensues, and (surprise!) in the end, it’s the client who pays, because they’re locked in.

What are the alternatives?

If the waterfall approach doesn’t work, what are the alternatives? I know of only one: Agility. This term may scare you because it’s been overused, yet Agility retains its full meaning.

Agility isn’t straightforward, I understand that: as a client, you’re putting money on the table without any commitment to results from your developers or your vendor.

However, you don’t invest €1 million right away. You invest €20,000 to €50,000 and observe the result, a software increment based on which users will provide you with feedback. Do a little and iterate frequently.

Thus, you commit resources as trust is built: trust in your vendor, but also trust that you are building a useful product, a good product.