Extreme programming (XP) gets results, but is it right for you?

If the term extreme programming is bringing up mental images of the X games and action sports, you’re not too far off. Extreme programming (XP) is, in fact, a pretty extreme way of programming. Similar to other Agile software development methods, XP uses adaptable, test-driven development for software engineering. But unlike other methods, extreme programming has strict rules and guiding values that govern how the work gets done. 

What is extreme programming (XP)?

Extreme programming is an Agile project management methodology that targets speed and simplicity with short development cycles and less documentation. The process structure is determined by five guiding values, five rules, and 12 XP practices (which we’ll break down further on in this article). 

Like other Agile methods, XP is a software development methodology broken down into work sprints. Agile frameworks follow an iterative process—you complete and review the framework after every sprint, refine it for maximum efficiency, and adjust to changing requirements. Similar to other Agile methods, XP’s design allows developers to respond to customer stories, adapt, and change in real-time. But XP is much more disciplined, using frequent code reviews and unit testing to make changes quickly. It’s also highly creative and collaborative, prioritizing teamwork during all development stages.

Extreme programming vs. Scrum

Scrum is another common type of Agile methodology managed by a Scrum master. Similar to XP, Scrum runs sprints off user stories to develop new product or software features. However, XP is more rigid than Scrum, with strict rules and guidelines that encourage constant contact between developers and the customer. Also, you can use Scrum for any process that requires iteration and customer input, whereas you’d only use XP programming.

Who created extreme programming?

The origins of XP date back to the late 1990’s, when Kent Beck created it to manage the development of a payroll software system for Chrysler called the C3 project. The goal with XP was (and still is) to remove the resistance to changing code within development projects. In more traditional software development methods, you’ll often leave code alone once it’s written (except for debugging). With XP, you scrutinize the code so carefully that developers may decide to re-write it entirely after a single iteration. 

When should you use extreme programming?

Because extreme programming focuses on software development, it's typically only used by engineering teams. Even in software teams, it only works in certain settings. To get the most value out of extreme programming, it’s best to use it when you: 

• Manage a smaller team. Because of its highly collaborative nature, XP works best on smaller teams of under 10 people. 

• Are in constant contact with your customers. XP incorporates customer requirements throughout the development process, and even relies on them for testing and approval.

• Have an adaptable team that can embrace change (without hard feelings). By its very nature, extreme programming will often require your whole team to toss out their hard work. There are also rules that allow other team members to make changes at any time, which doesn’t work if your team members might take that personally.

• Are well versed in the technical aspects of coding. XP isn’t for beginners. You need to be able to work and make changes quickly.

Lifecycle of XP

The XP lifecycle encourages continuous integration where the team member integrates almost constantly, as frequently as hourly or daily. But the full lifecycle breaks down as follows:

• Pull unfinished work from user stories 

• You prioritize the most important items 

• Begin iterative planning  

• Incorporate honest planning  

• Stay in constant communication with all stakeholders and empower the team  

• Release work  

• Receive feedback 

• Return to the iterative planning stage and repeat as needed.

5 values of extreme programming

Extreme programming is value driven. Instead of using external motivators, XP allows your team to work in a less complicated way (focusing on simplicity and collaboration over complex designs), all based on these five values.

1. Simplicity

Before starting any extreme programming work, first ask yourself: What is the simplest thing that also works? The “that works” part is a key differentiator—the simplest thing is not always practical or effective. In XP, your focus is on getting the most important work done first. This means you’re looking for a simple project that you know you can accomplish.

2. Communication

XP relies on quick reactivity and effective communication. In order to work, the team needs to be open and ‌honest with one another. When problems arise, you’re expected to speak up. The reason for this is that other team members will often already have a solution. And if they don’t, you’ll come up with one faster as a group than you would alone.

3. Feedback

Like other Agile methodologies, XP incorporates user stories and feedback directly into the process. XP’s focus is producing work quickly and simply, then sharing it to get almost immediate feedback. As such, developers are in almost constant contact with customers throughout the process. In XP, you launch frequent releases to gain insights early and often. When you receive feedback, you’ll adapt the process to incorporate it (instead of the project). For example, if the feedback relieves unnecessary lag time, you’d adjust your process to have a pair of developers improve lag time instead of adjusting the project as a whole.

4. Courage

XP requires a certain amount of courage. You’re always expected to give honest updates on your progress, which can get pretty vulnerable. If you miss a deadline in XP, your team lead likely won’t want to discuss why. Instead, you’d tell them you missed the deadline, hold yourself accountable, and get back to work. 

If you're a team lead, your responsibility at the beginning of the XP process is to set the expectation for success and define "done." There is often little planning for failure because the team focuses on success. However, this can be scary, because things won’t always go as planned. But if things change during the XP process, your team is expected to adapt and change with it. 

5. Respect

Considering how highly XP prioritizes communication and honesty, it makes sense that respect would be important. In order for teams to communicate and collaborate effectively, they need to be able to disagree. But there are ways to do that kindly. Respect is a good foundation that leads to kindness and trust—even in the presence of a whole lot of honesty. For extreme programming, the expectations are: 

• Mutual respect between customers and the development team. 

• Mutual respect between team members. 

• A recognition that everyone on the team brings something valuable to the project.

5 rules of the extreme programming methodology

The values of extreme programming are the more philosophical aspects. The rules, on the other hand, are the practical uses for how the work gets done. You’ll need both to run an effective XP team. 

1. Planning

In the planning stages of XP, you’re determining if the project is viable and the best fit for XP. To do this, you’ll look at:

• User stories to see if they match the simplicity value and check in to ensure that the customer is available for the process. If the user story is more complex, or it’s made by an anonymous customer, it likely won’t work for XP.

• The business value and priority of the project to make sure that this falls in line with “getting the most important work done first.” 

• What stage of development you’re in. XP is best for early stage development, and won’t work as well for later iterations.

Once you’ve confirmed the project is viable for XP, ‌create a release schedule—but keep in mind that you should be releasing early and often to gain feedback. To do this:

• Break the project down into iterations and create a plan for each one. 

• Set realistic deadlines and a sustainable pace. 

• Share updates as they happen, which empowers your team to be honest and transparent. 

• Share real-time updates that help the team ‌identify, adapt, and make changes more quickly. 

• Use a project management tool to create a Kanban board or timeline to track your progress in real-time. 

2. Managing

One of the key elements of XP is the physical space. XP purists recommend using an open workspace where all team members work in one open room. Because XP is so collaborative, you’ll benefit from having a space where you can physically come together. But that’s not always practical in this day and age. If you work on a remote team, consider using a platform that encourages asynchronous work for remote collaboration. This way, all members can continue to work on the project together, even if they’re not physically together.

As in other Agile methods, use daily standups meetings to check-in and encourage constant, open communication. You’ll want to use both a weekly cycle and quarterly cycle. During your quarterly cycle, you and your team will review stories that will guide your work. You’ll also study your XP process, looking for gaps or opportunities to make changes. Then, you’ll work in weekly cycles, which each start with a customer meeting. The customer chooses the user story they want programmers to work on that week. 

As a manager or team lead, your focus will be on maintaining work progress, measuring the pace, shifting team members around to address bugs or issues as they arise, or changing the XP process to fit your current project and iteration. Remember, the goal of XP is to be flexible and take action, so your work will be highly focused on the team’s current work and reactive to any changes.

3. Designing

When you’re just starting out with extreme programming, begin with the simplest possible design, knowing that later iterations will make them more complex. Do not add in early functionality at this stage to keep it as bare bones as possible.

XP methodology teams will often use class-responsibility-collaboration (CRC) cards to show how each object in the design interacts. By filling out each field in the card, you’ll get a visual interaction of all the functions as they relate and interact. CRC cards include: 

• Class (collection of similar objects)

• Responsibilities (related to the class)

• Collaborators (class that interacts with this one)

CRCs are useful for stimulating the process and spotting potential problems. Regardless of how you design, you’ll want to use a system that reduces potential bottlenecks. To do this, be sure you’re proactively looking for risks. As soon as a potential threat emerges, assign one to two team members to find a solution in the event that the threat takes place.

4. Coding

One of the more unique aspects of XP is that you’ll stay in constant contact with the customer throughout the coding process. This partnership ‌allows you to test and incorporate feedback within each iteration, instead of waiting until the end of a sprint. But coding rules are fairly strict in XP. Some of these rules include:

• All code must meet coding standards.

• Using a unit test to nail down requirements and develop all aspects of the project.

• Programming as a pair—two developers work together simultaneously on the same computer. This doesn’t add any time, but rather uses double the focus to produce the highest quality results. 

• Use continuous integrations to add new code and immediately test it.

• Only one pair can update code at any given time to reduce errors.

• Collective code ownership—any member of the team can change your code at any time.

5. Testing

You should be testing throughout the extreme programming process. All code will need to pass unit tests before it’s released. If you discover bugs during these tests, you’ll create new, additional tests to fix them. Later on‌, you’ll configure the same user story you’ve been working on into an acceptance test. During this test, the customer reviews the results to see how well you translated the user story into the product.

What are the 12 extreme programming practices?

To further hone the process, XP also uses a set of 12 practices throughout the process. They are based on the Agile manifesto, but adapted to fit XP needs:

1. The planning game: XP planning is used to guide the work. The results of planning should be what you’re hoping to accomplish and by when, and what you’ll do next.

2. Customer tests: When you finish a new feature, the customer will develop an acceptance test to determine how close it is to their original user story.

3. Small releases: XP uses small, routine releases to gain insights throughout the process. Often, releases go straight to the customers, though they can happen in-house.

4. Simple design: The XP system is designed for simplicity—you’ll produce only what is necessary and nothing more. 

5. Pair programming: All programming comes from a pair of developers who sit side by side. There is no solo work in extreme programming.

6. Test-driven development (TDD): XP’s reliance on feedback requires heavy testing. Through short cycles, programmers release automated tests and then immediately react.

7. Refactoring: This is where you’ll pay attention to the finer details of the codebase, removing duplicates and making sure that the code is cohesive. This results in good, simple designs.

8. Collective ownership: Any coding pair can change the code at any time, whether or not they developed it. XP produces code as a team, and everyone’s work is held to the higher collective standards.

9. Continuous integration: XP teams don’t wait for completed iterations, they integrate constantly. Often, an XP team will integrate multiple times a day.

10. Sustainable pace: The intensity of XP works requires you to set a sustainable pace. Teams should decide how much work they can produce in this way per day and per week, and use that to set work deadlines.

11. Metaphor: The metaphor is, quite literally, a metaphor. It’s decided as a team, and uses language to describe how the team should function. For example, we’re ants working as a collective to build up the anthill. 

12. Coding standard: XP teams follow one standard. In the same way that writers need to take on a brand’s voice to sound like the same person is always writing, XP developers code in the same, unified way so that it reads like one developer.

Intense, but effective

At this point, you’ve likely gathered that extreme programming is, well, extreme. The process is rigorous and highly structured, but the results might be worth it. XP’s unique development process incorporating customer feedback and intense, collaborative programming results in high-quality software. 

Streamline your XP planning and management with a work management tool that updates and adapts in real-time, just as your work does.