The iterative value proposition
After ranting on and on about focusing too much on basics and development techniques in agile discussions I guess it’s time to be more constructive. I have mentioned business alignment and added business value before so let’s dive into that for a moment.
For the purpose of this discussion I will stay away from agile software development and rather call it iterative development - emphasizing the focus on short time-boxed development cycles at the end of which a vertical slice of fully-tested and production-ready software is delivered. The value proposition here is manifold:
- Early exposure of a working piece of software to the business will make the software so much better - there is no doubt about that. The feedback gained early in a project will expose misunderstandings and/or different expectations between stakeholders. Early feedback will also keep the cost of change to a minimum.
- Early releases gives the business the option to use the software even with less features (frequent releases will gradually build up the feature list) and hence start reaping the benefits from the investment. Because the features with the most business value are usually prioritized first the software can start paying for itself and for the less important features. And coming back to the previous point I have seen quite a few projects where stakeholders decided to drop the less important features in exchange for changes they would have otherwise had to pay for. This allows a project to stay in budget and deliver totally aligned with the business needs (which of course can change).
- Recently I have stumbled across yet another benefit. Non-iterative (i.e. waterfall) projects tend to never really meet business expectations as business expectations are a moving target. Iterative (or agile) projects tend to not only meet them but also exceed them over the lifetime of a project. In the whole-of-life model we talk about the Outcome - i.e. the benefit realization - rather than the Output - i.e. the software. Watch this presentation here for a graphical representation:[youtube OWvSnYjqOTQ]
September 3rd, 2007 at 8:06 pm
[…] not only the typical arguments for agile software development but also the cost transparency and value proposition. Point out that the cheapest response is not necessarily the response with the least costs for the […]