eXtreme Programming is a process used to structure software development projects. It is radically different from more traditional methods, in that it defers more of the detailed planning till later in the project. Most traditional methods try to answer all the big questions up front. This makes it less susceptible to changes that occur during the project – something that can otherwise seriously disrupt software projects.

eXtreme Programming, or XP, is based on a set of principles that at first may seem awkward and counter-intuitive, but which actually support each other nicely, resulting in a process that is:

• More efficient
• More predictable
• More flexible
• More fun

Since I switched from the IT business to making people happy at work, I’ve used some of the XP principles in many other situations, where they have proved to work just as well. Here is my list of which XP principles translate to non-IT projects, and how to utilize them:

Frequent small releases

Rather than spending a long time building up to one huge release, find a way to divide your project into several smaller releases. This means that your product makes contact with the real world sooner, and allows you to better incorporate feedback from actual customers/users. in XP, you want to release something every 2-3 weeks, which is certainly preferable to working on a project for 6 months, delivering it to the customer and THEN learning that it doesn’t fulfill their needs. And don’t tell me this never happens.

Iteration planning

This means breaking the current goals down into tasks that are small enough to be accomplished in 1-3 days. Based on these estimates, the teams decides which tasks to include for the next deliverable. This means that the work immediately ahead gets broken down into small, manageable pieces and you can easliy track progress.

Move people around

Rather than assigning fixed roles to each person, let people switch roles. This enhances knowledge sharing and learning and also helps avoid information bottlenecks. XP also lets people choose for themselves which part of the project they want to work on.

Daily stand-up meetings

You’ll be amazed how much faster meetings go, when people can’t sleep in their chairs. in XP projects every day starts with a stand-up meeting to coordinate the days work.

The customer is always available

That way you don’t have to guess what the customer wants/intends/needs. You can easily and quickly ask.

Pair programming (or pair work)

This means that no work is done by one person alone – each and every task is tackled by at least two people. This may seem inefficient at first, but experience shows that people do better work when working together and it also enhances cross-training and team-work.

Simplicity

Choose the simplest solution that could possibly work. Don’t get fancy when simple will do.

Create spike solutions

If you’re faced with a difficult choice, don’t analyse it to death, trying to look for the right solution. Instead create spike solutions – quick tests that allow you to try various possible solutions out. This gives you fast, specific, real-life data to let you choose and helps avoid paralysis by analysis.

Collective code ownership (or collective project ownership)

Everybody owns the whole project. This helps avoid bottlenecks and that unpleasant situation where people feel that they own a part of the project and seem reluctant to share knowledge or accept criticism on their “property”.

No overtime

Period!

I believe that these principles can be applied to many kinds of projects and I have done so myself with considerable success. Are they always applicable? No. Read the XP entry on when to apply XP for some inspiration on when to use XP – and when not to.