One of the misunderstandings of agile methodologies is that there is no design or planning. I don't use XP, but I do use a mongrel of my own creation which borrows from Scrum, XP and Crystal. Instead of a massive requirements document, I write a feature list. I only work on a few features at a time (in 2 week iterations) and work with the user on getting that feature fully documented. Instead of an out of date requirements doc, I have a list of features with all the current information known about it. The user gets working software every 2 weeks to test and make sure it fits what they want. I've worked on too many projects that you spend a month writing a requirements document that the user agrees to, then you go off and write code for 6 months and when you deliver it, the user says "I didn't know it was going to work this way, it would be better if it did something else." Non-technical people can't visualize the way software is going to work based on UML and a Word document. They need to interact with the software. Agile allows me to adapt to my users' needs. My situation may be different from yours. I do not work in the software industry. I work for an engineering company. I design business apps for them to use internally. In a shrinkwrap software business, it may make more sense to design more up front. For me, I can walk down the hall and talk to my users face to face (not all of them, we have multiple offices). I think the key is that with BDUF, you get overcommitted to your code because it takes so long to get it in front of the user. Using short iterations, you never get overcommitted. Just my $0.02 Jeff Martin My Blog
