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.
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.
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.
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.
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).
XP projects create products in quick, frequent increments to mitigate project risk.
XP practitioners use a common language that everyone on the project is familiar with and understands.
Product developers use the simplest design possible and remove complexity as they develop products; they eliminate anything that doesn’t satisfy current requirements.
XP teams ensure high quality in products by implementing test-driven development (TDD) and constantly testing products.
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.
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.
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.
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.
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 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 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.)
- 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
- 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)
- 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)
- 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
- 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
- Guide the team’s efforts as design/infrastructure experts
- Help solve problems and simplify complex issues
- 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
- 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
- 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
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.
To test your understanding of the content presented in this assignment, please choose the correct answer
1. Which of the following statements about XP is true?Choose only one answer below.
a. It is more management-focused than most other Agile methodologies.
b. It avoids automation in its processes, preferring to let developers test products manually.
c. It relies on inexperienced developers to bring fresh, new ideas to projects.
d. It works best on projects in highly technical environments that contain vague or rapidly changing requirements.
Correct. XP works best for projects in highly technical environments where requirements are vague or change rapidly.
2. Which of the following is not an XP core practice?Choose only one answer below.
a. Pair programming
b. The planning game
c. Caves and common rooms
Correct. Although “caves and common rooms” are XP concepts, they are not one of the 12 core practices.
d. Small releases