What is Extreme Programming (XP) as an agile methodology?

It may surprise some readers that even though the Agile Manifesto was written in 2001, plenty of experimentation with what we now know as agile software development was underway well before its creation. For instance, during the 1990s, continuing experimentation was underway on what ultimately would be called scrum. And during that same period, agile practitioners were refining many other principles and practices, a significant percentage of which were more technically oriented.

In this article, we’ll take a look at Extreme Programming (XP) and see how agile software teams continue to apply its values and practices.

The origins and central concepts of Extreme Programming

The first Extreme Programming (XP) team worked on a rewrite of a payroll processing system at Chrysler Corporation in early 1996, and the new system went online in 1997 for a large subset of Chrysler employees. Since then, there have been scores of XP teams working to solve complex problems in many different business contexts.

The reasoning behind the choice of the term “extreme” is to indicate that the XP practices are much more central to the way that work is done when compared with traditional (waterfall) projects. That the intended result of XP is delivery of stable, working software on a predictable cadence.

XP consists of a set of values and a set of rules (practices) consistent with those values. The fact of the matter is that nearly all scrum teams are using XP practices — whether they realize it or not — and many of the agile planning constructs used in scrum are similar to those in XP.

What are the five XP values?

Just as scrum has five values, XP does as well. Both XP and scrum are internally consistent with the values and principles articulated in the Agile Manifesto. Let’s start by taking a look at XP’s values:

Simplicity

Prominent in the Agile Manifesto is the notion of simplicity, and XP practitioners often use terms such as “build the simplest thing that works.” Ultimately, keeping simplicity top of mind helps ensure consistent value delivery for the customer.

Communication

An XP team is small, self-managing, and places a lot of emphasis on effective communication. Face-to-face interaction is preferred whenever possible, while also recognizing that distributed teams too can communicate effectively using a combination of synchronous (e.g., Zoom calls) and asynchronous (e.g., instant messaging) techniques.

Feedback

XP places great emphasis on frequent delivery of working software, where customer feedback is vital. The notion of an “onsite customer” is also central to XP, where the team demonstrates what they’re working on to the customer on a regular basis. XP teams also value internal feedback and the continuous improvement opportunities that such inner team dialogue represents.

Respect

Respect exists across a number of axes. First and foremost is the respect that XP team members have for each other. Another important vector for respect is between the XP team and its customers, and another between leadership and the team.

Courage

We will tell the truth about progress and estimates. We don’t document excuses for failure because we plan to succeed. We don’t fear anything because no one ever works alone. We will adapt to changes whenever they happen.

Note: Scrum’s five values are commitment, focus, openness, respect, and courage.

What are the rules of XP?

Unlike scrum where there’s one place to look for formal definitions (the scrum guide), XP’s rules are described on multiple websites and in Kent Beck’s book Extreme Programming Explained: Embrace Change. The book was also released in a second edition and there were some changes to the rules, however, people follow both versions of the rules depending on what best suits their context.

The XP rules are intended to set expectations among team members, and to foster team collaboration and empowerment. Below is one way of articulating many of the XP rules, broken down into these categories:

• Short feedback loops
• Iterative and continuous development
• Shared understanding
• Respect for people

Short feedback loops

The XP rules that fall under this category help ensure that frequent feedback is available:

• Planning game — Planning in XP is consistent with general agile planning practices, where the atomic unit of work is a user story and the intention is to always focus on stories with the highest business value
• Whole team — By having all team members present for planning, including the customer/business representative, the idea is to ensure that everybody on the team is fully aligned with the product vision and how to iteratively build out features to realize it
• Test-first development — The two primary forms of test-first development are test-driven development (TDD) and behavior-driven development (BDD). In either case, the idea is to start by writing a failing test, then write code which makes the test pass, with the last step being to make the code better (refactoring)
• Pair programming — In pair programming, there is a driver and a navigator that frequently switch places, improving the quality of the code and helping ensure broader familiarity with the code base

Iterative and continuous development

Similarly to agile, this rule of XP emphasizes continuously improving the product:

• Continuous integration (CI) — To borrow the expression that a rising tide lifts all boats, the basic notion behind CI is to make code changes available to your colleagues as frequently as possible. The greater the time that goes by between code merges, the higher the potential is for merge conflicts
• Design improvement — Improving the design is the last step in test-first development and it can take many forms, such as refactoring based on one or more patterns or making the case to others to remove areas in the code that no longer serve a useful purpose
• Small releases — Releasing to production early and often is a core tenet of agile software development in general. Working in short iterations helps reinforce the idea that it’s preferred for features to go out in small batches

Shared understanding

A shared understanding is when everyone has a part in creating the end product and is working towards a common goal. There are some notable ways to achieve this, as outlined below:

• Simple design — The notion of simple design has much in common with the Lean idea of reducing or eliminating waste. Here are XP’s four simplicity rules, where simple code:
  • Passes all tests
  • Expresses every idea that needs to be expressed
  • Says everything only once
  • Has no superfluous parts
• System metaphor — In addition to ongoing communication and collaboration, the system metaphor is intended to serve as a simple narrative team members can align on to describe how what is being built is intended to work. For example, the system metaphor could consist of certain classes and patterns that shape the central flow of the system, where the metaphor might be to say the design is most like the steps involved in using a fancy espresso machine
• Collective code ownership — To help reduce risk and build familiarity across a particular code base, collective code ownership opens the door to team empowerment. Certain assumptions apply, for example, like when making a modification — the engineer keeps any existing unit tests running and adds additional unit tests for new functionality
• Coding standard — When working in a team context, it is particularly helpful to have agreed-to conventions for naming classes, variables, and methods, how to write code comments, etc.

Respect for people

This should be rather self explanatory, but the “respect for people” rule comes down to maintaining a sustainable pace. Far too many organizations make the mistake of expecting team members to work long hours with no end in sight — what has come to be known as a “death march.”

If the desired result is to get work done sooner, working at a pace that is not sustainable has the opposite effect where productivity decreases, morale is impacted, and team members depart.

Similarities and differences between scrum and XP

Agile software teams have many things in common. If you consider the case of a team that considers itself to be a “scrum team,” a common reality on such a team looks something like this:

• They have internalized the values, principles, and practices articulated in the Agile Manifesto
• They are following scrum practices which are intended to help their team collaborate effectively and frequently deliver value in an iterative fashion
• They are paying attention to the flow of work, using a Kanban board, and in many cases, applying other Kanban practices such as work in progress (WIP) limits
• They are following technical practices that are articulated in XP, such as CI, pair programming, collective code ownership, and coding standards
• They have adopted practices that are not part of any particular methodology, such as articulating a team working agreement

When it comes to what scrum and XP have in common, among the things you’ll find in the center of that Venn diagram are XP’s planning game (much like sprint planning in scrum) and whole team (analogous to the scrum team).

The simplest way to articulate how scrum and XP differ is that scrum says absolutely nothing about technical practices, while technical practices are a core part of XP. Interestingly, there are quite a few planning-related practices that many people assume are part of scrum, but which in fact originated in XP:

• User stories — Even though scrum teams articulate their work as user stories, this is a concept that scrum inherits from XP; user stories are not mentioned in the scrum guide
• Estimation — Although the vast majority of scrum teams perform estimation at some level, scrum inherits this practice from XP as well
• Velocity — Though a common metric on scrum teams, velocity is also not mentioned in the scrum guide, but it is specifically mentioned as being part of XP

Product management in XP

In scrum, one of the three areas of accountability on a scrum team is that of the product owner. In XP, the closest thing to a product owner is articulated as part of the whole team practice, that there needs to be a customer/business representative.

If you stop and think about it, both scrum and XP inherit the central importance of customer representation from the first principle articulated in the Agile Manifesto:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

To avoid making the cardinal mistake in software development — of building the wrong thing — there is no substitute for having one or more people consistently available to partner with teams who can act as the voice of the customer.

On an XP team, the customer representative might be a product manager, they might be an end customer, or they might be a person who frequently interacts with the customer. At the end of the day, the customer representative in XP is conceptually similar to the product owner in scrum, where they help with articulating requirements, setting priorities, and making sure there is shared understanding on the team when it comes to what customers care about most.

What is an example of XP?

Among the organizations that practice XP, Menlo Innovations, a custom software design and development, training, and culture transformation company, is one of the better known examples. They are very open about how they work and even conduct tours and workshops that are open to the public.

To summarize a few of the high points that are part of the Menlo Innovations process:

• Menlo’s means of ensuring the voice of the customer is ever-present and is to have what they call “high-tech anthropologists.” They spend a lot of time with the customer observing how they work and bring those findings back to the team
• A Menlo team includes a project manager (analogous to what XP calls a coach), where the project manager partners with team members to ensure there is transparency and visibility to the customer on an on-going basis. They do frequent “show-and-tells” (customer demos) and communication regarding prioritization and how the work is progressing
• Central to the process and the culture at Menlo Innovations is that there should be joy in the workplace. In addition to employing XP practices like test-first development and pair programming, there is consistent organizational emphasis on sustainable pace

Conclusion

XP has been around for a long time and its origin story follows a trajectory similar to that of scrum. Whether you are on an XP team, on a scrum team, or on a Kanban team, you are employing practices that originated in XP. Those practices will likely fall under one or more of the categories described previously: short feedback loops, iterative and continuous development, shared understanding, and respect for people.

At the end of the day, if you internalize and apply the values and principles articulated in the Agile Manifesto, along with the practices that are part of scrum, Kanban, and XP, you improve your ability to build the right thing and build it in accordance with proven principles and practices.

Featured image source: IconScout