In contrast, the well-planned iterative project starts from the expectation that people (developers, users, executives) are not very good at figuring out how they will actually use the product, estimate costs, prioritize features, or anticipate the problems they will encounter during development. It is designed to help us manage the risks associated with errors and omissions in our assumptions and estimates. We start with estimates. We build consensus around a broad vision for the product (rather than pretending to build consensus around the details), list features of interest and guesstimate their implementation times and costs, work with key stakeholders to prioritize the features, and then get moving on the implementation. Each time we add a feature, we also test it and fix it, stabilizing the product at the desired level of quality. Then we design, code, test, and fix the next feature, and the next. The product is incomplete, but from a point very early in development, the product is usable and testable and tested. From that point forward, people can use the product and give experience-based feedback that reveals erroneous designs, previously unidentified requirements, and bugs. The feedback drives changes in the priorities and details of what is implemented next.
Iteration gives management control over the schedule, cost, and feature set. They get increasingly accurate estimates because we regularly update our estimates of time and cost remaining to completion. They can stop new development at almost any time and (given a few final days of testing and fixing) have a product that works. I have seen this built-in flexibility used to salvage a project that had gone out of schedule control. (They shipped a product that worked, with fewer features.) I have used this flexibility to salvage a project that lost critical staff and could not be completed as planned. (We shipped the product early. It worked, but with few features. We then planned for a Version 2, as a separately budgeted project, to add all the features we had lost from this one.)
Note the tradeoff here: Features versus time, not reliability (and testing) versus time. What we release will work, in contrast with the waterfall, where we often release products with all the originally planned features, only some of which work.
The politics of iteration is also different. The conflict is no longer between testers and project managers. Instead, the people who cope with late tradeoffs are senior managers, marketing managers, development managers, and technical writers. The managers get to balance (and fund) the tradeoff between more time and more features. In XP, the managers have been able to prioritize the features throughout the project, so these tradeoffs should not be as bitter. Testers don't have to delay shipment, frantically reducing the number of known bugs at release. Testers don't have to fight developers and management to improve product reliability. Iterative development leaves management and the customer to decide the best balance of feature set and release date.
The nature of the tester's role changes in iterative projects. We are no longer the high-profile victims, we are no longer the lonely advocates of quality, we are merely (!) competent service providers, collaborating with a group that wants to achieve high quality. I think these are positive changes. I think we should consider them carefully before dismissing iteration in favor of processes that are as badly broken as, for example, the waterfall.