In a traditional approach to product delivery a specification is written and a development team formed. They work on the product for a number of months (sometimes years) and then it is released to it users and one go. During the development period people are being paid and cash is leaving the door at a steady pace. Income, the return on investment sought, for example, does not begin until the product is out there and being used. This is what it looks like as a financial model:
Now with an iterative approach we begin to deliver in small chunks or releases, trying to get a small but useful chunk of functionality to the users as soon as possible. At this first release, we may not generate the full impact we would want from the full product, but by getting it released means we start to generate some return. By the time we have the full product to market we are already generating steady income and will have a profile that looks something like this:
Comparison of the two profiles together shows the significant contrast between the two approaches. Providing the choice between these two approaches to any finance director or business leader would, in my mind, prompt a rapid decision.
This model does not take into account the other benefits incremental delivery:
- Gaining early feedback from users to ensure that the product is meting their needs
- Timely entry to the market for new product ahead of the competition
- The ability to fail early, can project and limit wasted spend if the market does not respond
- Reducing the impact of technical and commercial risk by addressing them early
