Notes:
As already discussed many of the techniques make assumptions about the project context. If the contextual requirements are wrong then don't apply the technique!
An example is the XP planning game – which assumes a lot of things about the management of scope and the relationship with the customer.
If the customer needs an explicit scope in order to get budget approval within their organisation, and cannot afford to commit time to the developemt throughout the project then you need a different technique.
But don't forget there are other forces resolved by the planning game: it prevents too much investment in long term plans that get overtaken by reality long before they are implemented.
It is interesting that Cockburn indicates that the primary classification he makes between methodologies is team size. My prediction is that as the size of the team grows “Agile” methods will become less distinctive. The intent to avoid products and processes will still exist, but the they will prove necessary.
For example, one of the things that I'm sure happens as projects increase in size is that the methods of communication they demand change. A some point it must become more effective to write documentation than to talk – not because documents are better at communication, but because the number of conversations required raises the cost of talking to a prohibitive level. (Of course, there are things that can be done to structure communications, and I don't know when these will fail, but fail they must.)