Agile vs XP

From my current understanding...

Agile is about high level principles, and best practices when developing software.

A manifesto is "a public declaration of principles and intentions"; and from the agile manifesto we get:

• "Individuals and interactions over processes and tool
  I interpret this as:
  When building non-trivial systems, we need to work as a team (including the client); A process is just the framework we work within to give the software development structure, and tools are the mechanisms used to create the software. The real value is created  when we extract requirements, and work out who is developing what, and what issues are being encountered.
  Without a high level of communication and interaction, we can't know what issues are currently present, and whether we're truly building something of value that solves the problems at hand.
  Therefore, the main focus should be on communicating with people, and getting feedback from people. Tools and processes are secondary, as they are more like catalysts (or helpers).
  
  
• "Working software over comprehensive documentation"
  I interpret this as:
  Write software that is simple and easy to understand, and which is user friendly. This will avoid having to write a large amount of documentation.
  
  
• "Customer collaboration over contract negotiation"
  I interpret this as:
  OK... first off, contracts will need to be made (to say what will be delivered for what money). The point is though, that the customer doesn't dictate what the requirements are through a contract - we are all part of a team that determines what will be in the contract. So the principle is that the client is actually part of the team, and requirements are 'discovered' rather than negotiated.
  
  
• "Responding to change over following a plan"
  I interpret this as:
  What developers have found in the majority of projects, is that
  "most projects have changing requirements". With traditional processes like the waterfall process, requirements were gathered all up front, and a big long plan was made of exactly how the system would be built.
  When requirements are changed however, it is then expensive to change, because you invested so much time up front creating, and planning the software design (which will now be for little use, as it needs to be changed).
  It therefore makes sense to structure the development process to incorporate the fact that requirements are likely to change (as history has shown it to be very likely). It also makes sense to be open to changes, as the end product should solve the given problem better, and make clients happier (which means they'll tell their friends, and you can charge more because you have higher demand ;))
  

Of course there are the other 12 principles, which say what we should be doing in order to be Agile. These tell us specifically the way in which we should be working.

Basically the principles say:

• Communicate well and often with clients and your team
• Ensure that the team has high levels of trust, motivation, and that work is done sustainably (e.g. not working everyone 60 hours a week every week).
• Learn about how to design software well, and use these learnings (build competence).
• Develop in short iterations so that you can get feedback from clients, and be willing to incorporate change requests (be flexible).
• Keep things simple (complex == complications).
  
• Look back and reflect on how you've done, and continually seek improvement and excellence.

OK, so then what the heck is Extreme Programming (XP)?
Well think of Agile as saying what to do (like an interface - it's abstract), and XP as one way to do it (a concrete implementation - it's specific)...

XP is an agile process, which means that it agrees with what the Agile Manifesto says. It has its own values, and has rules for doing things the agile way, as well as the Extreme Programming way.

XP says stuff like:

• The team must have a stand up meeting every day (for communication).
• Move people in the team around, so that they work on different parts of the system (to reduce risk of having only one person know about a particular part of the system).
• Do test driven development.
• Ensure you refactor your code to make it manageable.
  

I hope that what I've said is clear; if there's anyone that disagrees with anything I've written, I'd be happy to hear it :)

I'd also be interested to hear if anyone thinks that some of agile doesn't make sense. For me it seems quite logical, and it gives you a warm feeling - it seems like it's really about looking out for one another, being efficient, flexible, and effective.