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.
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.
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”.
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.
13 thoughts on “eXtreme Projects”
Thanks for a great post. On the pair programming, or pair work, I’d also add that one of the key benefits is the improvement in quality earlier. Far more defects/inaccuracies get corrected right at the point where they occur. And guess what – its cheaper too!
I would have expected to see the “write the test first” principle in there too. As an ex-developer who has led XP teams, I’ve since gone on to “pure” business project management. I’ve found real benefit, both for myself and the team, to first sit down and work out how we’re going to prove that is what we intended it to be.
Thanks a lot Dave, I’m glad you liked it. It would be nice to spread the XP approach more outside of IT.
Quality is definitely increased earlier in pair work. Good point.
I wanted to include test-first, but how is that adapted to non-IT projects? Got any ideas?
The test-first approach is not always appropriate but, thinking about how you’re going to QA a deliverable before you start creating it can often make life easier. A recent case in point has been when putting together a training syllabus and schedule. Before starting to write it a couple of team members and a customer spent 30-40 mins writing down all of the criteria it needed to satisfy to be considered worthy. It really helped us focus on what the customer needed.
BTW: Have you read the Scott “Dilbert” Adams’ stuff about “Out At Five (OA5)”? Its the best explanation I’ve ever come across about why overtime doesn’t work.
Excellent, great tip. I’ll update the post based on that. Thanks!
I’ve never heard of the OA5 stuff, but after some brief googling I can say that it sounds very sensible. Is it from one of his books?
Yes, its from “The Dilbert Principle”. A serious chapter tucked away amongst the serious comic strips!
Interesting ideas, but I’ve seen one drawback to XP.
I’ve watched the developers of a certain MMORPG seem to follow XP techniques. They had frequent small releases, iteration planning, and thanks to the games forums, the customer was always available day or night to comment on proposed changes.
The problem arises when management of XP is weak. There was constant development on the most important part of the game, as it was perceived by management. Developers were talking to the customer; management was listening to marketing.
I’ve seen XP techniques work, but unless management is there to keep everything in perspective and on track, it is doomed to failure.
After years of failed house projects (for example, clean out the garage) I’ve sucessfully been employing aspects of XP techniques. In particular
– Frequent Small Releases
– Iteration Planning
– Creating Spike Solutions
Kind of shocked my wife that I actually managed to complete a project…
That’s a great example, aetheogamous. I’ll try it for my next home project!