These ones are shared by all agile development methodologies. Referring more strictly to XP, talking about 4 mainpoints into this methodology is possible:

• There are four variables to be controlled: Cost, Time, Quality and Scope.
• Five values to be promoted: Communication, Simplicity, Feedback, Courage and Respect.
• Five principles that should guide us: Rapid feedback, Assuming simplicity, Incremental changes, Embracing change, Quality work
• The twelve practises: Planning game, small releases, simple designs, automated testing, continuous integration, refactoring, pair programming, collective ownership, 40-hour week, on-site customer, coding standard, metaphor

Nevertheless, the previous statements are not always true, depends on the team and they don't need to be followed strictly (one of the advantatges of XP is the lack of full strictness against heavyweight programming processes).

These diagrams could be self-explanatories:

As it is said before, XP needs to satisfy customer by early and continuous deliveries. There is a release planning at first. Once all is planned, programmer members do their work, iterating as several times as required. Once the bucle has finished, we have to consider if we have to change something (and replan), or all is OK and can be published. Once a version is published, the project must continue improving, or otherwise the project has ended.

In every iteration (iteration stands for a programming cycle and its acceptance) a little teamwork is defined (not strictly necessary, but highly recommended), and all is programmed and tested. If the code is not accepted nor satisfies the requirements, another iteration is made. Otherwise, the piece of code is tried to be integrated with the rest of the team. If the integration is succesful, the program can be published.

This is the main process in the XP methodology. The practise could be a bit different, but not too much.

As a summary, these two tables explains the differences between an agile methodology and a heavyweight methodology like RUP (where documentation – UML diagrams and other kind of documents made by analizers and designers - is very important in this last one because the teams used to be larger):

Although they are very different processes, an agile process could become a heavyweight development process in time, but it's not the aim of this post covering this.

Practise

Practise is slightly different. In the nwiki process, the process is:

1. First, there is a customer which needs some requirements which should be satisfied (Moodle 2.0).
2. Define the tasks in order to satisfy that requirements.
3. Have continuous reunions with the other teammates, and explain them objectives, purposes, workflow... all things about the project that needs to be developed.
4. Once all developers have understood the problem and have a minimum idea about de development process (how the project will be done), split the task between them.
5. Every X time, meet them to see how the state of the work is, changes on requirements, discussing problems, anything else...

Firstly, only a ewiki and old nwiki migration should be done. However, after Moodlemoot event, an ouwiki migration should be done too and ewiki parser will not be longer supported. This changes will be made with less cost than it could be if a heavyweight process was used (a demonstration for the advantatges of XP).

To sum up, a heavyweight programming methodology can be used in clearly defined projects (with an extensive analysis and specification), and projects where there are involved a huge amount of developers, and quality software becomes important. For smaller teams and projects which don't have too much time, Extreme programming could be a methodology to follow.