The author suffers from the common misconception that agile is a process for designing software. It is not. It is a process for implementing a design, while mai

The author suffers from the common misconception that agile is a process for designing software. It is not. It is a process for implementing a design, while maintaining flexibility to feed implementation experience back up into the design process. It's this feedback that the author's process lacks. FTA: "This [process] will take a few months, but when it is done we will know exactly what we have to build." Most of the time, experience has shown this not to be true; only when you've gotten into the implementation do you know what you 'have to' build (within some reasonable timeframe). That's because large software projects are typically nonlinear complex systems, where small implementation details can sometimes have large design consequences. There is no prohibition in agile from using UML, and the process is certainly not hostile to design. It may be that some people believe that using agile implementation processes relieves them of the responsibility to design their software, and that it's OK for user stories to be generated off the top of their heads without analysis. Those people are mistaken. Nowhere does agile promise to design your system for you.