This was the agile party line, but nothing in agile development helps with the core problem of changing requirements. If you design/code a solution to one set o

This was the agile party line, but nothing in agile development helps with the core problem of changing requirements. If you design/code a solution to one set of problems using an underlying set of assumptions and when someone shows up and changes those assumptions it doesn't matter if your using an agile process or a heavyweight waterfall process. The only difference is going to be in the amount of time it takes to iterate the design and tear the existing product apart and rebuild it with the new set of assumptions. The real savings with "agile" methodologies is the understanding that the code is the documentation. This doesn't free you from having requirements or design documents, it just allows you to spend less time on that part of the process. For any sufficiently complex project not having block diagrams of how everything fits together, and basic documentation of subsystem interfaces just means you waste a ton of time reading the detailed implementation before you can understand how the system works. In other words its the same problem you have with heavyweight processes. If you have to read 500 pages of design documents to understand how to integrate your routine, that is the same has having to read 50,000 lines of code to understand how to integrate a piece of code.