In my experience, i have found that you need to mix and match parts of different methodologies to suit your environment / situation. To use one exclusively is counter-productive. I prefer to initially approach a project with traditional project life-cycle and implementation methodolodies in order to get a very good and accurate idea of how the project will flow. This is important in a real-world environment because of clients. Clients have a vague idea of what they need, sometimes the only thing they know is that they need a new system based on the fact that the old one is either too slow or just doesnt work very well for them. First and foremost then it is important to analyse their situation and project plan so that you can present to the client and let them know what you think will benefit them the most and how long that will take. Along with this you introduce the idea of pseudo Agile in the sense that you make the client aware that things arent cast in stone once they give sign-off but at the same time they need to understand that they will be responsible for funding the changes in mid-execution. As far as i'm concerned Agile is only beneficial to the client or the architecht who has made a blunder.(it happens) XP is marvelous when you need to quickly write a fantastic algorythm. Two heads are better than one. But for normal 'construction / brick and mortar' programming XP is counter-productive. --- The world is the mollusc of your choice.