Feedback Has Value

A waterfall product development plan is created at the start of a project, and defines the development goals for the lifetime of the project. Subsequent development is managed to the plan. A good waterfall plan incorporates the most complete understanding customer need and development requirements possible at the outset of the project.

The concept of “good waterfall plan” is no oxymoron. The problem with waterfall development lies not in the planning itself, although planning can consume so more resources than it is worth. The problem lies in the strong assumption that waterfall development makes about feedback. Waterfall assumes that feedback adds no value.

Feedback from stakeholders or users received during development provides value by changing requirements. This takes two forms. The first is single-loop learning, through which you find a better way to reach the same goal. The second is double-loop learning, through which you find a better goal to shoot for. In either case the requirements change, contradicting the waterfall assumption.

If feedback provides any value, it will change requirements. Sticking to a waterfall approach in the face of valuable feedback increases the risk that users or stakeholders will reject the resulting product, and closes down opportunities to build something better than initially planned.

Although a waterfall plan may build a product iteratively, it typically does not. After all, the requirements are known. Why not just build it right the first time? The usual approach is to batch up similar work and perform each batch in turn, saving integration for last. This large-batch approach aligns well with the assumption that feedback has no value, as it closes down opportunities to collect feedback.

In contrast an agile approach usually implements a thin slice of end-to-end functionality, and adapts based on the feedback (i.e. learning) this produces. The feedback from putting early implementations in front of customers or customer proxies, and the changes in plan that result, are a primary benefit and focus of the agile approach.

Does this waterfall assumption hold in your development environment? How often do you know everything about a project at the outset, and learn nothing along the way that changes your understanding of customer value or functional detail?

The next time someone asks you whether a waterfall approach is appropriate for a particular project, ask them how they will incorporate feedback into their plans. Find out whether they believe that feedback has value. And if they believe that feedback does add value, help them take a more agile approach that lets them seek out and capture that value.

comments powered by Disqus