Extreme Programming vs agile
This article will explain the link between Extreme Programming and agile. These are both crucial concepts to understand in today’s world of software development.
What is Extreme Programming
Extreme Programming is one of the oldest and most famous of all the agile frameworks (along with Scrum, Feature Driven Development, etc).
It was started by Kent Beck in the 1990s. (This is also around the time that Ken Schwaber and Jeff Sutherland were working on Scrum). He was trying to find better ways to deliver a project at DaimlerChrysler. And came up with what we now know as Extreme Programming.
(Kent Beck ended up literally writing the book on Extreme Programming. Which is highly recommended).
The fundamental concept at the heart of Extreme Programming is the iteration (In Scrum this is called a Sprint).
Rather than plan out a long project, Extreme Programming focuses on working and planning in short iterations. Which have to be one to three weeks long. Teams pick an iteration length and then stick to it.
Work that doesn’t get finished in an iteration “spills over” to the next iteration. As opposed to extending the iteration to fit the work in.
Let’s look at the various Extreme Programming practices. More specifically, planning and development.
Planning in Extreme Programming
At the start of an iteration, developers and customers meet and discuss what can be achieved in the next releases and iterations.
First, customers and developers do some release planning. They discuss what features can be delivered in the next releases, and when those might happen. Release planning is divided into an Exploration Phase, a Commitment Phase, and a Steering Phase.
The Exploration Phase is where customers discuss their high level requirements. This includes grouping or mapping requirements into features or feature sets. The Commitment Phase is where customers and developers agree on commitments around what features can be delivered in a release. And when that release might happen. The Steering Phase is where plans can be adjusted and features added or removed, based on negotiations around the commitments that were made.
Then, the developers have a separate set of planning (without the customers). This is known as Iteration Planning.
Work to be done is described in the form of “user stories” (if you want to know how to write user stories better, make sure to read Mike Cohn’s book “User Stories Applied”). Developers break user stories down into tasks and estimate how long they will take using story points.
Estimating in story points help with capacity planning. That is, how much work can be pulled into the iteration.
After estimation, tasks are assigned to developers (this is different to Scrum, if you are interested in the differences in Extreme Programming vs Scrum).
At the end of these planning meetings, everyone has agreed on a high level plan about what user stories can be completed and when. These are of course forecasts, not commitments.
Development in Extreme Programming
Once development begins, this is where XP starts diverging from other frameworks like Scrum.
Extreme Programming is very specific and prescriptive about how work is to be done. All development must be done in Pair Programming. That is, two developers working together at the same time on one computer. This improves collaboration and reduces mistakes.
All work must be done via Test Driven Development (TDD). That is, tests are written first, then code is written to pass the tests, then the code is refactored and tests run again. Test Driven Development ensures that code is written with testability in mind. It also means that a set of automated regression tests are being built up.
Tests must be both at the unit test and acceptance test level. This ensures both developers and business people can confirm and agree the software is working as intended.
These development practices help enable continuous delivery.
Extreme Programming vs agile
Hopefully you can see by now that there isn’t really a “Extreme Programming vs agile” issue. Extreme Programming is actually a form of agile. It is one of the oldest and most respected agile frameworks.
Extreme Programming practices in agile implement many of the core ideas of the Agile Manifesto:
- Developers and Customers work closely together, through release planning and acceptance testing
- An on-site customer helps put the focus on customer collaboration (rather than contract negotiation)
- Pair programming and TDD enable quality and continuous delivery
- User stories ensure a focus on transparency, customer value and working software
- Small frequent planning cycles enable responding to change.
The only thing to keep in mind is that development practices in XP can be difficult for some. XP is much more prescriptive than other frameworks like DSDM or Scrum.
Test Driven Development and Pair Programming might not fit easily in some organizations. There could be technical or cultural roadblocks or resistances to these changes.
So think carefully about whether Extreme Programming is the right fit for your organization. Although it is very faithful to the ideas of the Agile Manifesto, the rules of extreme programming are not very easy to implement.
Summary
In summary, Extreme Programming is a powerful and successful implementation of the ideas and philosophy of agile software development. It is not very straightforward however, and you should do some research and thinking before implementing in your organization.
Do you have experience with Extreme Programming? Or more questions on this topic? Let me know in the comments! I will read and reply to every one.
