Incremental Delivery Incremental DeliveryExtremeProgramming 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
This page mirrored in ExtremeProgrammingRoadmap as of April 29, 2006