Extreme Programming XP
Extreme Programming (XP) is arguably one of the most important Agile methodologies. This is because XP is a set of software engineering practices that can be used by any team management methodology including Scrum, DSDM or any other for that matter.
Many of my early projects were successfully delivered using XP practices and, although they were not using Scrum, many aspects of the projects shared common values, which we will look at later on.
Bringing XP practices into an organisation first can be a way to introduce Agile from the bottom up. XP has 12 Practices, these practices are synergistic and complement one another. The following are Extreme Programming’s 12 practices :
- Small Release
- The Planning Game
- Pair Programming
- Sustainable Pace
- Team Code Ownership
- Coding Standards
- Simple Design
- Continuous Integration
- On-Site Customer
XP recommends that software projects should have frequent small releases, rather than fewer large releases as was typically the case with traditional waterfall projects. Iteration lengths are typically one or two weeks, with up to four weeks in duration. Small releases are preferable to large releases for a number of reasons. Small releases :
- give customers and the team early visibility of project progress.
- reduce time-to-market, as partial functionality can be released early on with subsequent versions to follow.
- increase team focus and motivation to deliver, as the end date is not too far in the future.
- reduce management and planning overhead. Planning too far into the future reduces the reliability and accuracy of plans.
The Planning Game
The Planning Game is where the customer allocates stories to releases and iterations within a release according to business priority. Since scope is varied within Agile projects, it is essential that high business value functionality is delivered first.
Prior to the start of each iteration the customer will select the highest priority stories for the iteration and the team will decompose these into tasks.
Refactoring is an XP practice which is critical to system longevity. Refactoring refers to the gradual improvement of code and design of an IT System without changing the behaviour or function of the system.
Refactoring is essential for the longevity of a system due to the decline that takes place
without this maintenance of code. To illustrate, imagine if we were to buy a building,
continuously use it, even add extensions to it, but refuse to maintain the portions already
built. Over time, slowly but surely, the building would start to deteriorate and crumble. So it
is with an IT system. The maintenance for an IT system is the purpose of the refactoring
Many millions of pounds have been spent on systems that have to be re-written after some years in operation. During this period of operation, the code base becomes increasingly fragile, with additions, patches, temporary code fixes, and hacks. This results in fewer and fewer people able to work on these systems, a system incapable of scaling and a massive reduction in project velocity.
An example of these fragile, inflexible and expensive system changes was demonstrated in the late 1990s with the ‘Millennium Bug’. Millions of dollars were spent leading up to the year 2000 just to change the ‘year’ field from 2 digits to 4.
One important reason for this system decline is the need to meet short-term business goals
which are often at odds with long-term business- and system- sustainability. IT professionals
under pressure from management and/or the client may resort to reducing quality in processes
and testing. Thus implementing hacks and workarounds to meet short-term project goals.
This frequently results in long-term system degeneration and is the reason behind the
typically short life-span of systems.
In a nutshell, if you want to ensure the life of your IT systems, refactoring must be a core
practice within your organisation.
As mentioned in Scrum 101: Introduction to Agile, testing must be built into the process from the beginning rather than a final phase towards the end of the project life-cycle.
Agile projects use a number of methods for testing, the most famous of which is Test Driven
Development (TDD) method. Rather than having a coder write some code and then write a
few tests which he has designed to pass his code, he firsts writes the tests based upon tests
provided by the customer and then designs and writes his code to first fail these tests and then
pass these tests. This means that you are only writing code that links to functionality required
by the customer. In turn this leads to less bloated software and increased quality, simply by
building testing into the process from the start.
This is not to say that TDD is enough by itself. Additional user-, performance- and security testing will still be required. Studies show that introducing TDD can result in a significant improvement to the quality of code written.
Perhaps one of the most controversial XP practices is pair programming. Here, two coders
work on a single piece of work together. Whilst this is a little more expensive in terms of
overall time spent, (about 15% according to Cockburn and William, 2001) it results in a
lower defect rate, faster problem-solving, and more brain-power applied to the same coding
task. After all, two heads are better than one.
“Never go to sleep without a request to your subconscious.” – Thomas Edison
I have to admit, coming from a traditional project management background, I understood the principle of a sustainable pace, but felt that it was somewhat at odds, with the ‘doing whatever it took to get the job done’ approach I like to take with projects.
It took no less than the founder of Scrum, Ken Schwaber’s thoughts on the matter to persuade me that this was a practice that was not just good from a team point of view, but also from a project delivery and team productivity point of view.
The most creative and tough problems are frequently solved at a subconscious level, this is where the larger portion of brain power resides. This is why our most creative moments, moments of inspiration or eureka moments are usually those which are away from working a problem, when we are doing some other non-related activity.
Some of the most creative people of the last century used to access the subconscious to create ideas and find solutions to problems that would evade most of us. For example, Leonardo Da Vinci was known to keep a book of questions, and leave his sub-conscious mind to continue to work on the answers.
When working normal hours, 8 to 9 hours per day, we give ourselves enough space, time and energy to digest and work the problem away from work at a sub-conscious level. We often find solutions to complex problems when we are away from the problem, and leave our subconscious to work on it.
Ken Schwaber, when talking about the importance of a sustainable pace, gives the example of Sammy Sega’s High Moon studios. When introducing scrum they worked to a sustainable pace of 8 or 9 hours a day. Upon increasing their work hours to 12 or 14 hours days, defects increased 60% and the cost of fixing the defects more than offset the additional work that they did, and so they reverted back to 8 or 9 hour days.
The problem is if you are not working at a sustainable pace, the problem gets worked less effectively, you end up with a less efficient solution, and less efficient design and code, and a less productive team overall.
Team Code Ownership
The objective of this principle is that there should be no ‘no-go’ areas within the code. In code without test harnesses, coders are frequently afraid of changing certain areas of the system particularly if they are fragile or badly designed, so as not to introduce unknown side effects. Under XP, the code should be ‘owned’ by the entire team, so this does not occur.
All programmers should adhere to a single set of coding standards to maintain consistency of code.
The idea is to keep the design as simple as possible to meet the project objectives. By keeping the design simple, maintenance, scalability and longevity of the system is increased.
A metaphor is simply a common vision that everyone should have for the project. By ensuring that the vision is clear, it is easy to ensure that decisions that are made along the way are in keeping with that vision. Additionally, psychological studies including Neuro Linguistic Programming stress the importance of visualisation in attainment of goals. Having a clear compelling vision of what your objective is and why you are doing it, can help a team through the tough times.
Continuous Integration is the practice of integrating new code into the system baseline code, automated building and testing on a frequent (at least daily) basis. The objective of this practice is to make Integration a ‘non-event’. The larger the team, the more important is the need to integrate code frequently to ensure that you are never far away from a workable release.
Continuous Integration may be automated using tools or may be done manually. James Shore mentions the following approach to manual CI :
- Before check-in, the developer should run the build and tests locally and make sure they pass.
- Tell people not to update from the repository because you’re doing an integration.
- Check in.
- Go to a different machine (often a dedicated “integration machine”), get the latest code from the repository, and make sure latest changes build and pass there, too.
- Done–tell people they can update again.
Last but definitely not least. This is perhaps one of the most important Agile principles that the customer must be accessible to the team on a frequent basis. Close collaboration with the customer will help ensure that what is required actually gets built, and ensure project visibility.
XP also advocates four values : Commitment, Simplicity, Feedback and Courage.