Laurent Bossavit has another excellent piece of insight: software processes can be viewed as risk models
This kind of thinking can help us to move beyond the religious software process wars. I've been frustrated by arguments from personal experience and anecdote that really fail to address the underlying reasons.
Risk is at the heart of it and the risks for every project are different. It makes no sense to talk about a process without saying what risks it is designed to address.
I'm particularly frustrated with criticisms of XP that focus on stand-up meetings and pair programming that concentrate on the mechanics. It's the risks that matter. Meetings are the classic productivity killers if done wrong and we (should) all know the perils of write-only code not to mention what can happen when a team loses cohesion. These are risks that need to be addressed, if not by the XP practices then by some other means.
The interesting thing for me is that problems with pair programming and stand-up meetings point to deeper people issues. These goes beyond the scope of any process but they perhaps the most important issues of all. People risks will usually outweigh any kind of technical risk.
The single biggest risk for projects in general is that effort will be wasted on features that are not used. There are many ways this can happen but they all come down to lack of communication and lack of feedback. It's hard to see how any good process can address this risk without incorporating agile values. Again, the details of any particular process don't matter, what matters is that we can identify and handle the risks that threaten our project. A process, agile or otherwise, is a model that can be taken and adopted for the risks facing the project.