The end result of most Waterfall-style projects looks like this:

How code quality evolves as the deadline approaches

quality vs time

The middle-to-end period of such projects is usually marked by vicious scope arguments, long hours, lots of bugs and lots of technical debt. Responding to change? Forget about it!

One common antidote is to start with an MVP (minimally viable product) to validate the larger project’s viability. Unfortunately, people who come from a Waterfall world usually treat MVPs as part of a 2-step process: e.g. doing a 6-week MVP to decide Go/No-go on a 2-year project. The leap from MVP to full project is still too large:

draw an owl

We’re still fighting over scope here; in fact, the arguments become even more onerous because multiple parties try to influence the scope of the MVP towards their particular agenda.

Instead, consider how a really well-run project embraces continous delivery. It produces a ready-to-deploy product very early in its lifecycle. If the project runs out of money somewhere in the middle, you’ll still have a valuable ($$$-generating) product. Balancing priorities is so much easier when you’re incrementally adding value. The real benefit? Such projects usually start paying for themselves halfway through:

MVP

Projects like this usually welcome changing requirements. You hear this over and over:

“The scope didn’t change; our understanding grew.”

The best tool I know of to do this is User Story Mapping. I wish we did more training as an industry on good product design, on “layering” incremental value on a product. Our failure rates would be so much lower!