While writing about Jason Bock's experience with XP I started feeling a bit bored with asking 'Does XP work or not?  Should everyone be doing XP?'.  I read Alistair Cockburn's PhD Thesis that presents a convincing argument that no one methodology will ever be the right way of doing things,  that clever teams will find ways of selecting their methodologies at the start of a project (he gives several key criteria) and that people are really the most important part of it (which is why I'm surprised that so many organisations fail to imitate Microsoft's well-known and documented hiring process).

No methodology is going to be a silver bullet

To me this is useful because it provides a framework from which to view XP and other methodologies.  So XP has some good practices in it, but the notion that it's the only way to do things, or that it will work on all kinds of projects and that all of the practices are required for a successful project is plainly silly.

Questions like 'Is Microsoft doing XP?' aren't really important.  What is important is that any development group thinks about what works, reflects on experience and experiments with new practices to see if they make sense. 

Big methodologies can inhibit reflection

Sometimes I think that the 'big name' methodologies are harmful because they reduce the likelihood that a team or project manager will reflect on their practices.  Methodologies are often attractive to management and project leads because they are packages as an easy solution to the difficult problem of thinking about what practices are best for a particular situation.  I know that RUP says you should customize the methodology to each project, but in reality I've rarely seen this happen.  It's much easier to just use the pre-packaged methodology than it is to think and reflect on experience to develop a custom methodology for each project.

Reflection and customised methodology are harder to market than a brand-name methodology

Saying "We're Agile" or "We use XP" is much sexier and easier to sell than saying "We understand a range of software development practices and use them to create our own methodology at the start of each project, based on the characteristics of the project and reflecting on our previous experiences".

I'm a big fan of the approach that Steve McConnell takes in Rapid Development where he presents a range of software practices that can be used.  For each one he details the amount evaluates things like potential to reduce schedule time, improvement in project visibility, effect on schedule risk, chance or first-time success and chance of long-term success.  The problem is that this isn't as easy to market as other methodologies. 

While I was writing this post I came across the following post from Bob Martin on the Yahoo XP Mailing List who seems to be saying that it's more important to focus on the practices and attitudes (such as the principles behind Agile manifesto) than it is on the brand names:

I'm noticing that the industry is adopting agile practices and attitudes without needing or wanting brand names. In the last year I've worked with a number of teams who started with SCRUM, or XP, or FDD, and who have since been picking and choosing practices from the other methods to suit their needs ... Instead of increasing specialization, the industry seems to be building a body of agile knowledge that it can use as a resource help them build something useful to them. It would not surprise me to find that in ten years the words Agile, XP, Scrum, and FDD have become synonyms.