The crux of the issue Cockburn raises is that "[d]anger grows when the results of [an] iteration are not directly linked to delivering the product to the end user."
To realize the benefits of iterative development, your iteration cannot simply be a development time period that culminates in testing and refinement of the plan for continuing development of the product. An iteration must result in a working release of the product to an end user. I have made this point in the past:
"With iterations, you perform the steps to yield a working version of the product for review."That is, the tests you run shouldn't just determine whether isolated features or pieces of the product work, but whether the end-to-end processes users perform are working.
Why is it so important for iterations to yield a working, releasable product? One reason I've mentioned:
"Implementing the product and demonstrating it to prospective customers almost always results in the discovery of new requirements or the recognition of errors in the original requirements."Another reason is that it prevents product developers from getting side-tracked. A developer might, for example, get bogged down implementing a particular feature. What's important, however, is not the feature itself, but what requirement it was intended to satisfy. If the developer is focused on satisfying the requirement instead of implementing the feature, she may (acting with "agility") simply choose to ditch the feature and satisfy the requirement by different means.