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 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.
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:
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.
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.
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 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.
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.
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:
The XP rules that fall under this category help ensure that frequent feedback is available:
Similarly to agile, this rule of XP emphasizes continuously improving the product:
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:
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.
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:
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:
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.
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:
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
LogRocket identifies friction points in the user experience so you can make informed decisions about product and design changes that must happen to hit your goals.
With LogRocket, you can understand the scope of the issues affecting your product and prioritize the changes that need to be made. LogRocket simplifies workflows by allowing Engineering, Product, UX, and Design teams to work from the same data as you, eliminating any confusion about what needs to be done.
Get your teams on the same page — try LogRocket today.
Value has many forms outside of the exchange of money for products/services. It can be in the form of saving time, increasing revenue, etc.
Concept evaluation bridges the gap between what seems like an out-of-the-world idea and what users truly need.
Nick Ehle talks about minimizing dependencies by designing teams and organizations to be as empowered as possible.
Value-based pricing is about using the perceived value, also referred to as willingness-to-pay, to set the right price points for the product.