When you first hear of Extreme Programming (or XP for short), it may conjure up images of developers coding while doing unusual feats of human endurance. Or maybe it sounds to you like a cavalier approach to coding where the aim of the game is to cut code quick and not worry about the quality.
In fact “Extreme Programming” is a very misleading name.
XP is one of the founding fathers of agile. It’s author Kent Beck co-wrote the agile manifesto, and has been on the forefront of agile thinking for the best part of 2 decades. He also invented TDD (cool huh, this guy is a dude!).
Change is inevitable
One of the main aims of XP was to enable a project to respond to change, as change is inevitable. But I wanted to make one thing clear here – change still needs to be approached in a measured manner. I have worked with lots of people from the design/requirements side who have suggested that it’s OK to change your mind on a whim in agile to such an extent that it causes chaos within the development team. I’ve also seen a common expectation that you can have fixed requirements and introduce changes and not see an increase of timelines if using XP. This is not the case. The aim is not to have fixed requirements, but if you have to, then add a decent chunk of budget to the unknowns, so that you do have room to change and are still able to meet your commitments.
What XP does give you is the flexibility to choose what you want built next and look at what has already been deployed to inform that decision. It gives you shorter turnaround times on necessary changes and sees change as a positive, if it is done for the right reasons.
Common Practices of XP
Some of the common practices of XP that you may have heard of are:
- Pair Programming
- Daily Deployments
- Continuous Integration
- Test Driven Development (TDD)
I’ll dig a little deeper into these practices another time, but to really get to grips with what XP is, you need to get away from the ‘how’ and first understand the ‘why’. If you get this then you kind of get the whole point of agile. And once you get this, the ‘how’s’ make so much more sense.
Values and Principles of XP
Values: Communication, simplicity, feedback, courage and respect.
Principals: Humanity, economics, mutual benefit, self-similarity, improvement, diversity, reflection, flow, opportunity, redundancy (as in this can be good), failure (as in this can also be good), quality, baby steps, accepted responsibility.
I am going to try and cover what I see as some of the core stuff you need to know about the values and principle of XP. Let’s see how I go…
1. It’s all about the people (Humanity)
All in all the idea is that if you create the right environment for people to thrive in, if you get a team working closely together, then you are going to see great successes. Communication is key, face to face conversations create better decisions and a healthy team environment where everybody is working towards a common goal. When the team are in control of their own destiny and they are seeing great progress and ownership over their work then this is when you are onto a winner. This is why colocation (i.e. all sitting together) is really important for XP and should be done whenever possible.
People often seem to miss this one out but it’s a bit of a linchpin to implementing XP – increased quality actually speeds up development. This might be tricky for some non-techies to get, but every developer will know what it’s like working on an old project. All the code is messy, you edit one bit and you literally have no idea what it’s affected and what it’s broken. When you get to this ‘house of cards’ point in programming you know you are fighting a loosing battle. There are lots of ways to improve quality but one of the key ways XP suggests is TDD.
TDD is fundamental to XP because it means as long as the tests have passed then you haven’t broken anything, it’s just so much easier! But the best bit about TDD is the idea that you are trying to get your code just to pass the tests, it should be coding the bare minimum, therefore you aren’t over-egging it and it should create simpler code.
Pair programming is also done because it increases quality. Bugs can be more easily spotted and designs can be discussed and thought through thoroughly.
3. Getting feedback quickly – learn from experience
This idea applies to all parts of the development life-cycle. If you quickly know if something works in the real world, you can learn from it and improve it. If you can implement design ideas just after they have been designed, you can see what really works in practice and be able to improve your design. If you integrate your code after completing only a small part, you will know if it has worked and more easily fix it as well as informing the rest of the integration piece.
The final aim is to be able to deploy to live regularly, even every day. But to do this, you need to have the quality in the project to be at a very high standard, so that you are not introducing bugs when you deploy. Therefore, you should start with other improvements such as TDD, and only after the improvements have proven to increase quality should you start to release more rapidly.
When you are able to deploy every day you are able to see more rapid return on investment. You will quickly be able to refine future requirements based on the performance of what you have already released. And you will be able to reduce the risk of the project. By releasing small pieces of functionality all along the project’s lifetime, you know how much of the project you have delivered and how successful it has been. With this approach, risks decrease rapidly over the period of the project. Rather than in Prince 2 big bang approaches, where deployment day comes with so many risks that you can barely fit them on your risk report.
Other interesting reads and further resources:
- The second edition of ‘Extreme Programming Explained’ is a complete re-write from the original and is the best place to go to learn more – ‘Extreme Programming Explained’ by Kent Beck
- Keep up with Kent Beck on Twitter
- You can also see a great talk on Youtube by Kent, and at the same time witness one of the best senses of dry humour in the programming industry.