Agile methods people claim changed requirements late in a project are not a disaster. Skeptics claim that's impossible, that it's like finishing the first story of a house and then deciding you want a basement.

That's a misguided analogy. The reason putting in a basement after thewalls are up is hard is because almost no one does it. If it wasdone to every house during construction, you may be sure thathomebuilders would have learned to do it as cheaply as is physicallypossible.

Agile projects don't think ahead: in iteration N, they don't pay much attention to what's coming in iteration N+1, much less iteration N+5. That means that every iteration brings with it a whole slew of what are, in effect, changed requirements. That trains both the software and the team to handle change as cheaply as is softwarically possible.

It's like the way that just-in-time inventory managementforces factories to improve their production process. Because theycannot buffer asynchronies with stock on hand, they are forced toremove them. (See The Machine That Changed the World.)