What is Extreme Programming?

December 12, 2021

7 minutes read

Extreme Programming (XP) is a highly collaborative Agile methodology that relies on extensive communication and interaction among team members.

Because it began as a software development process, XP has more of an engineering-bias and less of a management-focus than other Agile practices. It centers on the technical aspects of Agile practices—directing its efforts inward to help product developers create products—and incorporates a considerable amount of automation in its practices.

XP works best on projects in highly technical environments that contain vague or rapidly changing requirements. In Agile Software Development: The Cooperative Game, Alistair Cockburn explains that XP “is designed for small, collocated teams aiming to get quality and productivity as high as possible. It does this through the use of rich, short, informal communication paths with emphasis on skill, discipline, and understanding at the personal level, minimizing all intermediate work products.”

The method was dubbed “Extreme Programming” because software programmers were taking software development “to the extreme.” Practitioners decided that “if some is good, more must be better,” arguing:

If reviewing software code is a good idea, then it should be reviewed constantly as it is developed.
If testing helps create better products, then automated tests should be run multiple times a day.
If integrating code helps uncover problems, code should be integrated every day.

Continuously replicating the parts of development that add value to the product helps XP teams develop products of better quality that satisfy more customer needs.

XP Core Values

XP is based on four core values—communication, simplicity, feedback, and courage.

Communication

XP relies on extensive communication among team members to share information and to promote collaboration. Developers pair together to create products, and work with users on estimates and testing. Information radiators populate a shared work area that encourages osmotic communication and allows information to be quickly and easily conveyed throughout the team.

Simplicity

XP practitioners perform only the amount of work needed to meet that day’s requirements, with an understanding that more work may be needed on subsequent days to fix or adapt the product. Because they avoid creating features that may go unused, products are kept simple and adjustments should be minimal.

Feedback

XP puts a strong emphasis on feedback throughout a project. Developers gather timely feedback by developing products in teams, running extensive daily tests to ensure products function as envisioned, and holding frequent conversations with customers and team members; this immediate feedback allows developers to quickly adjust processes and product characteristics to meet expectations. Tracking the team’s velocity against the release plan also provides regular feedback on team progress. And putting the completed product quickly into production provides a quick check of customer acceptance and suitability.

Courage

XP requires courage on the part of the development team to make the difficult decisions needed to deliver value to customers. Developers are expected to move quickly and decisively, with the courage to make adjustments as they see fit, and try new ways to get results. They must have a belief in their abilities and be encouraged to push forward to deliver results.

XP Core Practices

XP practitioners use 12 core practices to express these core values. Because the application of each of the 12 practices helps to reinforce the strength of the others and contributes to the success of the project, all 12 practices should be used in concert in every XP project.

The Planning Game

XP teams determine what subsequent product releases will entail by balancing business/customer priorities (from the product owner) and technical estimates to complete the project tasks (from the development team).

Small Releases

XP projects create products in quick, frequent increments to mitigate project risk.

Metaphor

XP practitioners use a common language that everyone on the project is familiar with and understands.

Simple Design

Product developers use the simplest design possible and remove complexity as they develop products; they eliminate anything that doesn’t satisfy current requirements.

Continuous Testing

XP teams ensure high quality in products by implementing test-driven development (TDD) and constantly testing products.

Design Improvement/Refactoring

Developers simplify product characteristics, add flexibility, and improve product performance without changing the product’s functionality or behavior; they use comprehensive automated tests to speed up the development process by ensuring that refactoring doesn’t introduce new problems.

Pair Programming

XP teams create products by having two people develop and review the product simultaneously; alternating the developing and reviewing roles provides different viewpoints and ensures quality and consistency.

Collective Ownership

All team members “own” the product so developers can improve the product in any way at any time, as long as they follow the rules and standards ascribed to the project.

Continuous Integration

XP teams integrate completed tasks into a completed product multiple times each day.

Sustainable Pace/40-Hour Work Week

XP practices limit developers’ time at work to prevent overwork and ensure an adequate work-life balance.

Whole Team/On-Site Customer

Customers (or a customer proxy) must be included and accessible to XP teams at all times to answer questions.

Coding Standards

XP processes specify the rules, practices, and standards to be used on the project to ensure that all code (or product characteristics) can be understood and modified by all team members.

XP Teams

XP works best with small-to-medium-sized teams of experienced developers. Team members must be knowledgeable enough to create TDD tests and experienced enough to contribute to pair programming.

Because of the reliance on extensive verbal communication and a need to work together on development, it is very important for XP teams to be co-located. One suggested layout for co-located teams involves a large central area surrounded by several smaller areas—a configuration Ken Auer and Roy Miller called “caves and common rooms.” In this configuration, the center of a room is designated as a group work area, which acts as a large meeting area and assists osmotic communication and the sharing of information. The outer edges of the room are divided into smaller areas that allow developers to complete their work or hold smaller discussions. Participants in caves and common rooms must be working on the same project; otherwise, discussions of alternate projects in the common area can distract developers from their work.

XP Roles

XP teams have many “roles” that team members must fill. These roles are not specific “jobs” staffed by specialists but instead are responsibilities that must be performed to create effective XP teams. (XP practitioners still avoid filling teams with specialists, preferring instead to develop generalists who can handle multiple types of tasks.)

On-site customers/proxies

Identify features and/or stories they would like to see in products
Help decide which features have the most value and should be included in each release
Provide answers to team questions

Product owner/manager

Document the product vision and share it with stakeholders
Create and prioritize features and stories
Incorporate feedback and make trade-offs of features/stories
Provide direction for on-site customers and lead customer demonstrations
Protect the team from outside distractions and “office politics”
Participate in the planning game with the development team

Subject matter experts/domain experts

Fill in knowledge gaps
Provide details and answer questions for the team
Create customer tests (occasionally)

Interaction designers

Understand user needs as they relate to interacting with the product and advise the team of user priorities
Create personas and perform interviews with customers
Review prototypes with customers and observe customer use of the product
Create mock-ups and prototypes (occasionally)

Business analysts

Analyze customer needs and translate them into functional specifications
Support on-site customers
Help the team translate technical terminology into language that customers will understand

Product developers/programmers

Execute the project work and develop products
Produce complete products in each iteration
Provide suggestions for alternative ways to accomplish tasks
Develop estimates as required and minimize costs by working as efficiently as possible
Correct any quality or technical debt issues encountered
Participate in the planning game with product owners/managers

Designers/architects

Guide the team’s efforts as design/infrastructure experts
Help solve problems and simplify complex issues

Testers

Help customers think of possibilities/potential features
Ensure product quality
Identify holes in product development
Provide nonfunctional data (product performance, scalability, stability) to the team

Coaches

Act as project leaders who lead by example, not by assigning tasks
Staff the team and secure an appropriate workspace
Keep the team focused on the tasks at hand and help the team interact with the organization
Help the team succeed

Project managers

Coach the team on nontechnical issues (project managers often do not have technical experience, so they avoid interfering on technical issues)
Help the team work within the organization

Scalability

XP is limited in its scalability; it can be scaled to tackle larger problems and projects, but is not ideal for projects with larger teams. Because XP uses very little documentation and relies on team interaction to share knowledge, project information resides within the team members themselves—not in documentation. Adding additional members to the group makes sharing that knowledge much more difficult. As the group grows, it is harder to interact with every team member on a regular basis and the knowledge that could be shared among team members in those interactions is lost.

Who is Using XP?

Many organizations employing XP have reported extraordinary results. Sabre Airline Solutions, a producer of airline and airport-services software, boosted the productivity of its programmers in one project by 42% when they switched to XP practices mid-project. Escrow.com, an Internet transaction-management organization, saw a 67% increase in development velocity, an 80% reduction in overhead costs, and a 70% reduction in the number of defects found during acceptance testing after converting to XP. And Litle & Co, an Internet payment processing company, successfully employs XP by developing six-week iterations to upgrade its interfacing software every six months.