Financial Effects Of Iterations

The question of whether to develop and deliver software in one or in several iterations has some aspects which are more related to financial engineering than software engineering:

Cash flow effect: The part of the software delivered earlier than it would have otherwise starts to generate cash in-flows for the customer earlier. And a dollar today is worth more than a dollar tomorrow.
Risk effect: Iterations are checkpoints for the customer and allow stopping the project and still (hopefully) having a defined, usable state.
Tax effect: More than one iteration may allow you to declare the iterations as updates, or upgrades, or fixes, or ... . I don't know about US law, but with German laws, it does make a tax difference.

-- FalkBruegmann

ScottAmbler in the ProcessPatternsBook says that incremental delivery has lower overall project cost to achieve the same final deliverable. I don't believe it, having experienced the delays of frequent "synchronization" points. I prefer incremental delivery primarily for reduced risk and increased customer involvement.

One thing to be aware of with incremental delivery is that when our new system replaces an existing system, it doesn't make sense for the customers to use the new system until it's at least as good as the old system. Also some support groups, like QA and operations, are still (in 1999!) having a hard time working with anything but a single "big bang" AcceptanceTest and release point. (I find it remarkable how many "QA testing" groups are still completely in the dark on automated regression testing!) -- JeffGrigg

Sadly, it seems that many of the developers upstream of QA are also in the dark, or at least in the twilight, about automated regression testing. Sadder still, management often colludes by setting up incentive systems that reward the illusion of positive progress without punishing for negative progress (i.e., regression). The only organizations I've seen take advantage of automated test suites are those that have grown beyond HeroicProgramming. -- DaveSmith

I believe the most dramatic financial effects are those that stem from the use of iterations as options- AnalyzingXpWithOptionsPricing. -- KentBeck

Indeed. Think of each subsequent release (iteration) as an option on the preceding release (iteration). Some value is delivered at the end of each release, upon which the next-release decision is made.

That's backwards and might be a different meaning of the word 'option'. What AnalyzingXpWithOptionsPricing is talking about, and what I think KentBeck is talking about, is the use of "real options". These are similar in concept to stock options, and in a software development effort would be used to estimate the value of go/nogo decisions, design alternatives, release dates, and so on. For example, finishing the current iteration might be seen as "buying the option" to start the next iteration after that. In that context, each preceding iteration is an option on (an option to buy) the subsequent iteration; certainly not the other way around.

Comparing a single-release project with an equivalent double-release project (with costs and benefits equally distributed between the releases), we can show through real options analysis that significant value can be created when the benefits are subject to uncertainty. The more uncertain the benefits are, the more value frequent releases generate. -- HakanErdogmus

I have a theory that another effect of iterations is that management thinks the software is nearly ready long before it really is, e.g. if you can show a running program then it must be almost shippable. In the GoodOldDays? :-), by the time the program ran it was almost shippable. The time period between when the program first runs and the time it is ready to ship is of course TheTimeWhenDevelopersDoNothing?.

If this happens, it is because the team is not effectively communicating what needs to be done, what is actually done, and how well it works. See CommitmentSchedule, AcceptanceTests, and other topics here, and http://www.armaties.com/wewilltry.htm on Armaties for some starting ideas. (There's a WeWillTry here as well, which I'm improving slowly in moving it to Armaties.)

One problem that some projects have is that the developers want to polish the system forever. Or, sometimes some critical component is left to the end and turns out to be hard to do. These are among the many problems that a properly-managed incremental development can help with. -- RonJeffries