eXtreme Programming (XP) was one of the most wildly known and used agile methodologies back in the early 2000s. XP was the brainchild of Kent Beck, Ron Jeffries and Ward Cunningham, based on their collective experiences at Daimler Chrysler. Its name became marmite and put off management. It incorrectly evoked visions of surfer dudes and lack of professionalism.
XP is an iterative methodology. Teams plan a small amount of work and build it in short timeboxes called iterations of 1 to 4 weeks. The main difference between XP and other iterative frameworks is that XP focuses on software engineering practices that it takes to extreme levels. For example, much research suggests that code reviews are one of the most effective ways to find defects. XP takes this to the extreme and encourages peer reviews 100% of the time through pair programming.
Not only does XP focus on short iterations, but it also prescribes short release cycles to reduce risks inherent in technical product delivery. Schedule slips, stale requirements misalignment with customer needs, business changes and unnecessary features are addressed by short release cycles.
XP practices have continuously evolved since Kent Beck first published “Extreme Programming Explained”. However, the following graphic presents the set most commonly associated with XP.
XP included values into the methodology decades before the Scrum framework adopted them. The four XP values are:
- Communication. Keep the right conversation flowing to reduce problems occurring.
- Simplicity. Do a simple thing today, rather than create gold plating that you may never need.
- Feedback. Feedback loops with the system, the customer and from each other drive solutions.
- Courage. Make hard decisions to help you deliver at top speed.
XP stipulates specific roles. It has a strong emphasis on programmers and expects the programmer to take on the joy of testing their code. XP programmers need both broad technical practices but also effective communication and interpersonal skills to implement practices such as pair programming.
Despite the development team performing the balance of testing, XP requires testers. The role of tester shifts to helping the customer define and write acceptance tests.
All software projects have a customer. XP takes the customer role to the extreme requiring colocation with the development team, and they must be able to make decisions about the product and specify the behaviour of the system in the form of user stories.
To support the team, XP includes a tracker who provides the team with valuable feedback on how well they are performing using data. There is also a coach to help the XP team achieve higher levels of performance.
Learn more in our BCS Foundation Certificate in Agile.