107325669673871907

Thanks Chris for the wonderful welcome.

I’ve been following the discussions here on jazz and improvisation in project management and it reminds me of one of my favourite tools these days: eXtreme Programming.

The thing that really makes XP interesting is, that it’s been designed for a changing world. Remember tat big project you’d been working on for months, really giving it your best with your team mates, when suddenly the requirements changed, or the customer changed his mind or your boss got a new idea or… In many projects this would mean that a lot of work will be lost, but the XP methodology was designed not to function in spite of this – XP was designed for a world where this kind of thing is inevitable and will happen all the time. XP projects eat unscheduled changes for breakfast.

Extreme Programming was defined about six years ago by Kent Beck, and though it is nominally a method for structuring softare development projects, it has applications way beyond that. I used to be a software developer, and have tried the method in it’s intended field where it is a true revolution compared to the way we used to do things. These days my interests are in making people happy at work, and in crafting an organization of people who work for this purpose, and I find again and again that the lessons I learned from eXtreme Programming (or simply XP) can be used here also.

This is possible because XP is based on a number of rules, and here are a few of my favourites:
User stories. This means, that instead of writing long pages of specifications about your system, you write stories about the users, and how they use the systems. This is essentially a narrative approach, one which is much more in tune with how our minds work. Stories can give you a less precise but much more robust understanding of the goal you’re trying to achieve.

Small releases. Rather than aiming for one big release of your system in six months, you aim to deliver something every 1-3 weeks. This keeps you focused on the specific job ahead of you, rather than on some problem that may or may not arise in a few months.

Move people around/pair programming/collective ownership. Nobody does just one thing, and nobody works alone. In XP projects you see two programmers at every computer, because every task is tackled by two people working together. This means that no area of the system is known or “owned” by only one person, making your project much less vulnerable.

Simplicity. My favourite. XP states that you should always do the simplest thing that could possibly work. This is practically my mantra these days and it’s immensely liberating. Don’t think ahead six months. Achieve your current goals, then move on to something else.

These are just my favourites, there are many more rules in XP that you can explore yourself, and almost all of them can be translated from the world of programming into almost any kind of project.

Also there are obvious parallels between XP and Open Space Technology like Common ownership, Simplicity and meetings where project participants stand in a circle. Also XP is essentially open source, meaning anyone can buy the book and run their own XP projects.