I had an enjoyable day today working alongside Mark White, a consultant (and all round clever guy) at Microsoft in the UK.  Amongst other topics, Mark asked me a great question about the difference between Extreme Programming and Agile Development.  I said that I thought the fundamental difference was that XP was based on a more prescriptive set of practices (Test First, Planning Games, Paired Programming etc) whereas Agile Development was more a philosophy (based on focussing on the people issues of software development and doing things that worked).

At a drinks event tonight I spoke with a developer from ThoughtWorks who backed up my idea.  He said that one of the challenges was that Banks and Finance companies didn't like the idea of doing anything 'Extreme' so Agile was a better way of describing it.

I was interested to hear though that ThoughtWorks mix their Agile approach with large-scale multi-national development.  As the Agile Manifesto says, an Agile approach is about individuals and interactions over tools and process and customer collaboration over contract negotiation.  One of the key points of XP seems to be about communicating and talking with people, both within the team and between the team and the customers.  It strikes me that these principles may be challenged by large-scale projects worked on by geographically disburse teams (even if, as the ThoughtWorks developer said 'they are all clever people').

I also think there are great challenges with doing an XP approach on large teams.  In order for this to work I believe there has to be an overriding architecture that lets the large project act like lots of small teams.  To me large-scale projects with teams in different countries make it very difficult to practice agile or Extreme Programming.  Still, it's interesting watching ThoughtWorks as a test bed for Agile methods on large scale projects.

Mark also mentioned that the Microsoft Solutions Framework (framework, not methodology) could still add something to XP or Agile approaches with it's notion of the Team Model.   I particularly agree that these approaches could be improved with the role of Program Manager, but perhaps that's just my bias.