Extreme programming (XP) is an agile software development framework that focuses on a set of values and practices. These values and practices lead to higher quality software, and higher quality of life for developers.
XP is the most prescriptive of the agile frameworks when it comes to appropriate engineering practices for software development.
The key belief of teams practicing XP is that if a team does a specific minimal set of engineering practices extremely well, they will be much more successful and have much more rewarding software development experiences.
The name extreme means a team should perform those engineering practices as well as possible, almost to the extreme. “Extreme” doesn’t imply that the engineering practices themselves are necessarily radical (although some consider some of them pretty far out).
Extreme programming history
XP was first used in the mid 90’s on the Chrysler Comprehensive Compensation (C3) program. Kent Beck switched the team to XP when started on the project to improve the performance of the system.
He wound up adding a couple of other folks, including Ron Jeffries,and changing the way the team approached development. The XP framework came into focus over the course of this project. In addition, several of the people on the project wrote books about the framework. These books spread knowledge about the framework, leading to wider adoption of XP.
Primary contribution
XP’s primary contribution to the software development world is an interdependent collection of engineering practices that teams can use to be more effective and produce higher quality code.
Most teams adopting agile start by using a different framework and implement XP when they realize the need for more disciplined engineering practices.
Product managers should get familiar with XP, even though the framework focuses on engineering practices. If for no other reason, these practices, when followed properly, will help your product team create higher quality software.
XP values
The founders of XP identified five values that they believe provide a purpose and direction for your team’s work:
Communication
Simplicity
Feedback
Courage
Respect
Communication
Software product development is inherently a team sport. Creating a product that solves your customers’ problems requires more than one person.
You need a team, and the biggest key to team effectiveness is proper communication.
Communication is so important because that’s how team members transfer knowledge between each other. You want everyone on your team sharing the same knowledge using the most effective form of communication possible.
For a long time, that “most effective form” was face to face discussion with the aid of a white board”.
Given improvements in technology and a continuing move toward remote work, a new definition of the most effective form may be the approach that provides the richest form of communication in your given scenario.
If your team does happen to be working in the same room, then face to face discussion at a whiteboard probably is the best route to go. If your team is remote, you may try asynchronous communication via writing supplemented by voice chat on Slack.
Simplicity
The idea of simplicity is finding “the simplest thing that will work? Not “the simplest thing we can do (that may not work at all)”. You focus on simplicity to avoid waste and do things that are only absolutely necessary.
Simplicity means keeping unnecessary complexity out of your product so that it is easier to maintain, support, and revise. This idea also extends to making your product intuitive so that your users enjoy using your product.
Simplicity also means to produce only the outputs needed to solve the outcome you’re currently trying to deliver. In other words, address only the problems that you know about, don’t try to predict the future.
Feedback
The only way you can perform practices extremely well is to continuously learn and improve your skills. Feedback is a key aspect of that learning.
Through constant feedback about your previous efforts, your team can identify areas for improvement and revise your practices.
Feedback also supports the simple design concept. Instead of doing a large design effort up front, it is much more effective for your team to build something, gather feedback on your design and implementation, and then adjust your product going forward. In other words, it fits in nicely to cycling through continuous discovery and delivery.
Courage
Kent Beck defined courage in the context of XP as “effective action in the face of fear” (Extreme Programming Explained).
This definition shows a preference for action based on the other principles. That ensures the results of the action are not harmful to the rest of your team or the product.
You need courage to:
Raise organizational issues preventing your team from being as effective as you can be
Stop following an approach that feedback has shown is not working and try another one
Accept and act on feedback, even when it is difficult to accept.
Respect
In order to establish an environment that supports the above values your team needs to exhibit respect.
Your team members need to respect each other in order to communicate with each other, provide and accept feedback that honors the relationship, and to work together to identify simple designs and solutions.
XP practices
The interconnected set of engineering practices listed below form the core of XP. While you can adopt these practices in isolation, you’ll get the best lift from implementing most, if not all of them at the same time.
Adopting the projects that complement each other reduces the risks the practices address.
The practices are:
Sit together
Whole team
Informative workspace
Energized work
Pair programming
User stories
Weekly cycle
Quarterly cycle
Slack
Ten minute build
Continuous integration
Test first development
Incremental design
Most of these practices are focus on engineering, though some deal with how your product team plans your work and collaborates.
It’s helpful for product managers to be aware of all of these practices if your team adopts them.
You may also find yourself suggesting one or more of these practices if your team faces some of the challenges that these practices address.
Sit together
If your team members live in the same city and come into the same office, you should sit together so that you can have the most effective communication possible.
Of course as we’ve discovered over the course of the last couple of years, it’s not always desirable, or possible for your team to work in the same place.
Does that mean you can’t work together?
Not all. The reason for the sit together practice is to enable communication. If you have a team working in different places, think about how you can recreate the effective communication that comes from everyone working in the same room even when they are not.
One technique that some remote teams find helpful is to have an open voice channel in Slack, Zoom, or Google Meet. You don’t need to have video cameras on, and you can stay on mute unless you need to talk to someone.
This approach works if your team establishes an agreement on how you’re going to work together (let the team know when you’re stepping away from the chat) and there’s a high level of trust amongst the team.
Whole team
The practice of whole team calls for a cross functional product team that includes all the necessary skills to discover and deliver your product.
This means the team includes a product manager, product designer, engineers and anyone else with the necessary skills work together on a daily basis to accomplish desired outcome.
Due to the focus on the whole team, there are very few roles defined in the XP framework in particular. Your team needs to determine what skill sets you need to deliver a successful product.
Informative workspace
When your team works together in the same physical space, you want to make sure that space encourages collaboration. That usually means the space:
Facilitates face to face communication
Allows people to have privacy when they need to get into a flow
Makes the work of the team transparent to each other and interested parties outside the team.
When you’re working in a remote setting, you need to create a virtual space for your team that has the same characteristics.
Energized work
The concept of energized work means that your team needs an environment where you can focus and you are able to devote a good chunk of every day focused on thought intensive efforts.
Not only does that mean do not overwork yourself, but it also means stay healthy, and show respect to your teammates to keep them healthy. If your team follows the practices of sit together and pair programming, one of the worst things you could do to your team is show up sick.
Not only are you not productive, but chances are, you are going to infect some of your team members as well. That could lead to a huge impact on your team as a whole and everyone on it, all because someone was trying to be a hero.
Stay home. Get healthy. Your team will thank you for it.
Pair programming
Pair programming means all production software is developed by two developers sitting at the same machine.
The idea behind this practice is that two brains and four eyes are better than one brain and two eyes. You effectively get a continuous code review going on, as well as quicker response to nagging problems that may stop one person dead in their tracks.
Pair Programming has its share of detractors. The biggest concern is when two developers work on one computer the team will only get half as much done compared to if everyone worked solo.
Teams that use pair programming have found that the practice improves quality because they are able to work through problems quicker and they stay more focused on the task at hand. The pair produces less buggy code and less unnecessary code so the end result is a much more manageable code base.
User stories
User stories describe what a customer or user is trying to accomplish with the product. They often serve as a reminder for a more detailed conversation about a particular aspect of the product and are often used for planning purposes.
As a product manager, you’ll often find yourself writing and managing user stories as your team works through building your product.
The developers on your team make use of user stories to write acceptance tests that are done even before product code is created.
Weekly cycle
The weekly cycle is the name for an iteration in XP.
In a weekly cycle, the team meets on the first day of the week to reflect on progress to date, the product manager (probably filling the role of the “customer” in XP) picks the stories they would like delivered in that week.
The team breaks the stories into tasks, estimates them, and establishes their commitment. The goal by the end of the week is to have running tested features that realize the selected stories
The intent behind the weekly cycle is to produce something to show for feedback. The weekly cycle also provides a short enough time frame that if your team heads in the wrong direction, worse case you are redoing only a week's worth of work.
The purpose of the quarterly cycle is to keep the detailed work of each weekly cycle in context of the overall product.
During a quarterly cycle, the product manager (filling the XP customer role) lays out the overall plan for the team in terms of the desired outcome for a particular quarter. This gives your team a view of the broader product while they focus on specific details.
It also helps you work with other areas of the organization such as marketing and operational areas who may need some idea of when features will be available in order to prepare marketing plans or training.
In the quarterly cycle information about any particular user story is at a relatively high level, the order of user story delivery within a quarterly cycle can change and the user stories included in the quarterly cycle may change.
Since you’re able to revisit the plan on a weekly basis following each weekly cycle, your team can keep everyone informed as soon as those changes become apparent to keep surprises to a minimum.
Slack
The XP practice of slack means to have some lower priority user stories in your weekly and quarterly cycles that you are willing to drop if your team gets behind on more important stories.
This practice allows you to account for the inherent variability in estimates to make sure you leave yourself a good chance of delivering the user stories necessary to deliver the desired outcome. It provides your team the space it needs to address the unexpected such as production issues or un anticipated absence of a few team members.
Ten minute build
The goal with the Ten-Minute Build is to automatically build the whole system and run all of the tests in ten minutes.
The founders of XP suggested a 10 minute time frame because if your team has a build that takes longer than that, you’re less likely to be run on a frequent basis.
This practice is intended to encourage your team to automate your build process and to run all of your automated tests during the build. This approach allows you to repeatedly verify that changes did not accidently cause harm to something that was already developed.
This practice supports the practice of continuous integration and is supported by the practice of test-first development.
Continuous integration
The practice of continuous integration calls for developers to merge their code into the main branch several times a day.
The idea is that if you experience problems every time you integrate code, the more frequently you integrate, the less code you have to look through to find and fix the issues.
This practice requires some extra discipline and is highly dependent on ten minute build and test first development. If you’re running your build multiple times a day, you don’t want it to take forever. Also, you want to integrate code that is already tested so that you know any issues that do arise are from interactions with other bits of code.
If your team implements continuous integration you’ll need to setup ground rules surrounding what to do when a build breaks.
Most teams adopt the rule “you break it, you fix it”, meaning that whoever checked in the code that causes the build to fail has to fix the build before they can introduce any new changes to the system.
Test first development
The practice of test first development means that you write unit tests for the changes you make before you write production code. The intent with this practice is to ensure that all new code is covered by unit tests.
In other words, Instead of following the normal path of:
Develop code
Write tests (maybe)
Run tests (perhaps)
A developer using test first development follows the path of
Write failing automated test
Run failing test
Develop code to make the test pass
Run test
Return to step 1.
This practice has several benefits:
Tests are automated so they can run frequently.
Writing the test before you write the production code gives you a clear idea of what “done” means.
Since you are expected to write tests for all new code, you’re less likely to introduce extraneous code into the product.
Tests encourage you to follow good design principles of loose coupling (modules are independent so that a change in one module is less likely to have an adverse impact to another module) and high cohesion (all of the functions of a module are highly related)
You inherently create a set of regression tests as you build out your code base.
As with continuous integration, test first development reduces the feedback cycle for developers to identify and resolve issues, thereby decreasing the number of bugs introduced into production.
Incremental design
The practice of incremental design calls for you to take a breadth first then incremental deep dive approach to the design of the code for your product.
You initially establish a broad, but shallow understanding of the product. Then only dive into the details of a particular feature when you’re implementing that feature.
This approach reduces the cost of changes because you don’t do too many detailed designs too early so you don’t have to change them as your understanding changes. Instead, you make code design decisions when necessary based on the most current information available.
One activity key to this practice is refactoring. Simply stated, refactoring is changing the way software does something without changing the end result.
Refactoring is an excellent practice to use to keep the design simple, and one of the most recommended uses of refactoring is to remove duplication of processes.
Successful refactoring is highly dependent on the presence of test first development and continuous integration to act as safety nets. If you do not have a means to verify that you did no harm to existing code, it can be very dangerous to try refactoring on any large scale.
XP roles
Because XP places so much emphasis on the practices for software developers to follow, there’s little guidance on specific roles for the people on the team.
That may be one reason why many teams that adopt XP end up using another framework (such as scrum) to structure their team and look to XP for the engineering practices.lifecycle
When roles are identified in XP, it’s typically these four:
Customer - The role responsible for making the decisions about what features are included in the product. This is the role that a product manager fills on a team using XP.
Developer - The people on the team who are responsible for realizing the user stories identified by the customer.
Tracker - One of the developers who takes tracks relevant metrics the team feels is necessary to identify areas for improvement
Coach - Someone who has used XP before and is helping a new team adopt the practices.
XP lifecycle
As with roles, XP does not have a prescribed lifecycle. To understand what a lifecyle looks like for a team using XP, let’s examine how your team might use the quarterly cycle and the weekly cycle:
Describe the desired outcome and define the set of user stories that you think will deliver that outcome.
If there are any user stories where your team doesn’t understand all of the technical considerations involved, you can do a spike. Spikes are short, time-boxed efforts set aside for the purposes of doing research to clear up technical uncertainty. Spikes can occur before regular iterations start or alongside ongoing iterations.
Your product team works together to create a release plan that everyone feels is reasonable. This release plan is a first pass at what user stories will be delivered in a particular quarter, or release.
Your product team launches into a series of iterations (the weekly cycle). At the beginning of each iteration, your team decides which user stories to work on during that iteration.
At the end of the iteration, review progress to date and you decide whether you should continue work on the product, or if you’ve built enough to get the desired outcome.
Why product managers should care about XP
Let’s face it. XP is a framework built by developers for developers. What’s more, it was created by developers who were consultants to a large enterprise to build a compensation system.
That’s why the primary decision maker is called the “customer.” The founders of XP assumed that teams using the framework will be working for a client company whom they expect to provide sole guidance on what to build.
The true value of XP to product teams comes from the practices that provide guidance to developers on how to develop with quality.
For example, if your team is able to adopt a combination of ten minute build, continuous integration, test first development, and incremental design you’ll be able to deliver code changes frequently and with high quality. This allows you to have short feedback cycles and ensure you making the delivering what you need to get your desired outcome.
Kent McDonald
Read also
Prioritize with confidence
