Incremental Delivery

See also IncrementalDevelopment, a near-synonym.

ExtremeProgramming Projects work in short iterations. Every iteration results in a release of a working system. Earlier iterations have less functionality than later ones, but the same high level of quality.

Actually, many project methodologies use this model. It probably originates with TomGilb, and has many variations. It is alternatively referred to as TimeBoxing, EvolutionaryPrototyping, IncrementalDevelopment, IterativeDevelopment, and many others. XP is by no means the only life cycle model that uses short time-boxes (or EVOs, in Gilb's EvolutionaryDelivery), each producing an evolving deliverable.

There is a more general topic at work here - release early and release often. If you have to replace a legacy system with a million contracts, one way to apply incremental delivery is to put 10 contracts into production in the new system after a few weeks or months. You will have to create the necessary scaffolding so the systems can both operate or you may have temporary duplication of information (like addresses).

Alternatively, you might implement one function out of the thousand that the legacy system implements and put it into production after a few weeks or months.

IncrementalDelivery spends extra effort to inter-operate in return for the reduced risk of early feedback.

It's also important to note that customers don't know what they want (or need, which is not the same thing) until you show them the potential. Then they get ideas. Then you put the features of 1.0.4 on your plan of record.

Not only for customers, but for all ProjectStakeholders?. For example, as SteveMcConnell mentions in RapidDevelopment, time-boxing provides a heart-beat, a rhythm of delivering that provides the engineering team with a sense of accomplishment each time they deliver on time. This is why many say it is better to take UseCases (requirements) out of an EVO (or time-box) and ship on time than it is to do everything and let the EVO end late.

Incremental delivery implies incremental change. Sometimes, though, it seems that incremental change can be a minor headache. Mathematics is full of derivations where the intermediate results are larger and more complex than the beginning or the ending. This can happen in software, too. Suppose, for example, that your C++ program uses a large switch statement, and it has hundreds of cases, and you want to convert it to use an array of function pointers instead. How can you do that incrementally? For a while, you have to have an incomplete table of function pointers that falls back on the switch statement -- you have to have both. Eventually, though, simplicity returns, as all the cases are eventually converted into functions. -- EdwardKiser

For something like that you shouldn't check it in until you are finished; however the rest of the project will still have been moving forward in that time and can be delivered on time. -- AaronRobson

Is "IncrementalDelivery" a synonym for "IncrementalDevelopment"? To me, IncrementalDelivery implies actual deployment to a customer and for many situations, 1-4 deliveries per year are the maximum acceptable. I believe you can do IncrementalDevelopment, but still only have periodic delivery. --WayneMack

Incremental Delivery is what we use on large projects, not necessarily software. When producing large, in-depth content, the one of the friendly and usable ways we use to keep the customer satisfied is a constant shootout of betas. For complex content like printing projects, web sites and custom software (we don�t develop software, though), constant customer participation is vital. A customer that does not assign people and time to his service providers, anyhow, hardly can be considered qualified to deserve quality. --Mathias R�e

CategoryExtremeProgramming