Extreme Programming (XP)

If this agile methodology is less popular today, Extreme Programming (XP) still influences today’s Scrum and various agile movements that emphasize technical excellence, such as Software Craftsmanship and DevOps.

I’ve mentioned it in various articles, but I’ve never written an article specifically about this agile methodology that was very popular in the early 2000s. Many people know its name, but very few know what it entails in practice.

Origins of Extreme Programming

Kent Beck, Ward Cunningham, and Ron Jeffries experimented with a new project management method in 1996 on the C3 project at Chrysler, which gave birth to this methodology. It was officially presented in 1999 in the publication “Extreme Programming Explained.”

The 5 Values of Extreme Programming

Extreme Programming is based on five essential values that I will briefly present here:

1. Communication: Extreme Programming insists on excellent communication within the team. Communication is the foundation of smooth operation.

2. Simplicity: It is essential to think KISS (Keep It Simple, Stupid) and to develop only what is necessary. Developers should not try to anticipate things, even if it means refactoring later.

3. Feedback: Extreme Programming (XP) emphasizes the importance of delivering quickly to get feedback as early and as often as possible. This is why XP proposes short development cycles.

Unit tests (with TDD) and automated functional tests (e.g., BDD) are also fast feedback on the technical aspect of the product. Having these insights quickly prevents overlooking bugs in production.

4. Courage: It is essential to have the courage to sometimes accept radical changes. One should not persist with a practice or architecture that is not suitable but have the courage to choose new ones.

5. Respect: Although this value was not initially present in 1999, Kent Beck quickly added it to Extreme Programming to emphasize the importance of respecting the people we work with, whether within the team or not.

Iterations in Extreme Programming

Like many agile methods, Extreme Programming insists on short-duration iterations. Each iteration should start with an Iteration Planning where the team defines the work to be done during that iteration.

XP (Extreme Programming) requires choosing user stories that provide the most value to customers within each Iteration Planning. Considering that Extreme Programming recommends sustainable rhythms, key users (or their representatives) should plan the iteration based on the previous velocity.

Incidentally, the user stories used today in Scrum, as well as the concept of velocity/predictability, originally came from XP. In Scrum, it’s actually the development team that decides what it can accomplish.

The content of these iterations will consist of user stories (functional requests) and technical tasks.

Iterations in XP typically last between 1 and 3 weeks. However, you should also incorporate Iteration Releases into your projects using this methodology (a concept that has been adopted by some in Scrum).

Every morning, except on the day of the Iteration Planning, the entire team holds a Daily Standup to synchronize, just like all Scrum teams.

The team may also conduct retrospectives from time to time when the method is no longer 100% suitable and needs improvement.

Here’s a simplified representation of Extreme Programming:

Some Elements of the XP (Extreme Programming) Framework

Now let’s look at several rules imposed by XP that curiously appear in many mature Scrum teams.

Today, this has become quite common, but XP (Extreme Programming) insisted that the team should be co-located in an open space and maintain a sustainable pace.

For exploratory phases, XP recommends using Spikes, which we’ve already discussed in a dedicated article—these are time-boxed and unestimated requests.

Article: What’s a spike?

However, XP proposed estimating in ideal days (the number of days to complete the request without considering any time constraints and ignoring ceremonies). While this estimation method was used in many companies in the past, it’s a practice that has been largely forgotten in France, where estimation in “effort points” is firmly established.

Testing is Feedback

This framework that advocates technical excellence imposes the implementation of various software engineering techniques. This ensures a quality framework: TDD, BDD, Pair Programming (coding together on the same workstation), coding standards, etc.

A release cannot go into production without implementing these practices.

Roles in Extreme Programming

1. The Checker: This role regularly checks with developers to see how things are going. If an issue is identified, they ensure that action is taken promptly. In Extreme Programming, it is emphasized not to let problems persist.
2. The Customer Representative: This individual writes user stories and performs functional tests that validate all scenarios required by the user stories. They also take responsibility for prioritizing requests for developers.
3. The Developer: This person is responsible for developing the application. They have a broad skill set, estimate user stories, and can provide input on the content of user stories.
4. The Tester: This role sets up functional tests and is the guardian of the test results. If tests fail, they notify the entire team.
5. The XP Coach (Extreme Programming): The XP coach helps the team achieve a high level of maturity and continuous improvement. They also assist in planning meetings and facilitate them. In some cases, the Checker and the XP Coach can be the same person.

Conclusion – Extreme Programming

Indeed, Scrum, as seriously applied in companies today, has incorporated all these elements. One could even speak of Scrum XP because all the principles of Extreme Programming are part of the Scrum framework we see every day.

Please note: The spelling “Extrem programming” is a spelling mistake. It should be written as Extreme Programming.