Building a Minimum Viable Product

When developing on a Waterfall project, the criteria by which you develop to are determined by the specifications. This is both a blessing and a curse, in that the decisions about what to do are external to the development team.

The general issue with design by specification is each part is of equal value, in the sense that it's presented as an all-or-nothing proposition. And since everything is designed upfront, it has to cater for all conceived features - no matter the actual value.

With agile, features are organised and developed by value. The idea is to create a minimum viable product, where the features developed are those that will be the those that add maximum business value.

There are two really good reasons for doing this:

1. If development needs to stop at any time, then what's delivered will reflect the greatest value.
2. Most software features turn out to be either never or rarely used.

To me, both issues come down to the problem of trying to sort out the needs of a system upfront. Design, especially on detail, is constrained by the development costs - something difficult to work out in advance. And the value of features is something that can only really be seen once the system is live, so anticipating that is going to involve guesswork.

Keeping in mind the possibility that development could wind up tomorrow puts pressure on the actions of today. Each day a product is not delivered is a day the value of the product is not being realised. By focusing on MVP, the outcome is delivering sooner, delivering something that addresses the needs, and thus represents the best value of the time and effort of everyone involved.