Extreme Programming (XP) is an agile software development methodology. Like other agile methodologies, XP has its unique tools, processes, and roles. The creator of XP, American developer Kent Beck, didn’t invent anything entirely new but instead took the best practices of agile development and amplified them to the extreme, hence the name Extreme Programming.
The methodology’s author, Kent Beck, led the Chrysler Comprehensive Compensation System project in the late ’90s, where he first applied XP practices. He documented his experience and the created concept in the book “Extreme Programming Explained,” published in 1999. This book was followed by others detailing XP practices. Contributors to the methodology’s development include Ward Cunningham, Martin Fowler, and others.
Unlike other agile methodologies, XP is exclusively used in software development. It cannot be applied to other businesses or daily life like Scrum, Kanban, or Lean.
The goal of XP is to cope with constantly changing requirements for the software product and to enhance development quality. Therefore, XP is suitable for complex and uncertain projects.
XP revolves around four core activities: coding, testing, designing, and listening. Additionally, Extreme Programming has core values: simplicity, communication, feedback, courage, and respect.
13 Practices of Extreme Programming
1. The Whole Team
All project participants using XP work as a single team. This team must include a customer representative, preferably a real end-user knowledgeable about the business. The customer sets the product requirements and prioritizes functionality. Business analysts can assist the customer. From the executors’ side, the team includes developers, testers, sometimes a coach guiding the team, and a manager providing resources.
2. Planning Game
Planning in XP occurs in two stages: release planning and iteration planning.
- Release Planning: The programming team meets with the customer to determine the desired functionality for the next release, typically in 2 – 6 months. Since customer requirements are often vague, developers clarify and break them down into tasks that can be completed in a day or less. The customer must understand the operational environment where the product will work.
Tasks are recorded on cards, and the customer prioritizes them. Developers then estimate the time required for each task. Once tasks are described and estimated, the customer reviews the documentation and approves the start of work. For project success, it is critical that the customer and the programming team play on the same field: the customer chooses genuinely necessary functionality within the budget, and programmers appropriately align the customer’s requirements with their capabilities. - Iteration Planning: Conducted every two weeks, sometimes more or less frequently. The customer is present to define the functionality for the next iteration and make changes to the product requirements.
3. Small Releases
XP releases are frequent but with limited functionality. This approach makes it easier to test and maintain the system’s operability and provides the customer with business-value functionality every iteration.
4. Customer Tests
The customer specifies automated acceptance tests to check the functionality of the product. The team writes these tests and uses them to test the code.
5. Collective Code Ownership
In XP, any developer can modify any part of the code, as the code does not belong to its author but to the entire team.
6. Continuous Integration
New code parts are integrated into the system immediately — XP teams release a new build every few hours or more frequently. This practice ensures that recent changes’ impact on the system is visible immediately. If a new piece of code breaks something, identifying and fixing the error is much easier.
7. Coding Standards
With collective code ownership, adopting common coding standards is crucial to make the code look like it was written by a single professional. Teams can develop their standards or adopt existing ones.
8. System Metaphor
The system metaphor is a comparison with something familiar to create a shared vision within the team. Typically, the person developing the architecture and seeing the system as a whole devises the metaphor.
9. Sustainable Pace
XP teams work at maximum productivity while maintaining a sustainable pace. Extreme Programming discourages overtime and promotes a 40-hour work week.
10. Test-Driven Development (TDD)
One of the most challenging practices in XP. Programmers write tests before writing the code to be tested. This approach ensures that each functionality piece is fully covered by tests. When developers commit code, unit tests are run immediately, and all tests must pass, ensuring the team is moving in the right direction.
11. Pair Programming
Imagine two developers working at one computer on a single functionality piece. This practice is pair programming, the most controversial practice in XP. The saying “two heads are better than one” illustrates its essence well. From two solutions to a problem, the best one is chosen, code is optimized immediately, and errors are caught before they occur, resulting in clean code understood by both developers.
12. Simple Design
Simple design in XP means doing only what is needed now, without trying to predict future functionality. Simple design and continuous refactoring create a synergistic effect — when the code is simple, it is easier to optimize.
13. Refactoring
Refactoring is the ongoing process of improving the system’s design to meet new requirements. It includes removing code duplication, increasing cohesion, and reducing coupling. XP mandates constant refactoring, so the code design always remains simple.
Advantages and Disadvantages of XP
XP is controversial and often criticized by those who failed to implement it. However, its benefits are apparent when the team fully utilizes at least one XP practice.
The benefits of striving for XP include:
- Customer Satisfaction: Customers get the product they need, even if they don’t initially have a clear vision.
- Flexibility: The team quickly makes code changes and adds new functionality due to simple code design, frequent planning, and releases.
- Reliability: Code always works due to constant testing and continuous integration.
- Maintainability: The team can easily maintain the code because it is written to a single standard and constantly refactored.
- Productivity: Rapid development pace due to pair programming, no overtime, and customer involvement.
- High-Quality Code
- Risk Mitigation: Development risks are reduced as responsibility is evenly distributed, and the project is not jeopardized by the departure or arrival of team members.
- Cost Efficiency: Development costs are lower as the team focuses on code rather than documentation and meetings.
Despite its advantages, XP does not always work and has several weaknesses:
- Customer Involvement: Success depends on customer involvement, which can be challenging to achieve.
- Unpredictable Timelines: It is difficult to predict project time costs as the full list of requirements is unknown at the start.
- Dependency on Skill Level: XP heavily depends on the programmers’ skill level and works best with senior professionals.
- Management Resistance: Management often opposes pair programming, questioning the need to pay two programmers instead of one.
- Cost: Frequent meetings with programmers can be expensive for customers.
- Cultural Changes: Implementing XP requires significant cultural changes.
- Lack of Structure: XP’s lack of structure and documentation makes it unsuitable for large projects.
- Non-functional Requirements: Functional requirements are challenging to describe as user stories in agile methodologies.
Principles of XP
In his first book, Kent Beck outlined the following principles of XP: simplicity, communication, feedback, and courage. In a subsequent edition, he added a fifth principle — respect.1. Simplicity
XP development starts with the simplest solution that meets the current functional need. Team members consider only what needs to be done now and do not incorporate functionality that might be needed in the future.
2. Communication
Communication in XP occurs live rather than through documentation. The team actively communicates with each other and the customer.
3. Feedback
Feedback in XP is implemented in three ways:
- System Feedback: Through constant module testing.
- Customer Feedback: The customer is part of the team and participates in writing acceptance tests.
- Team Feedback: During planning, concerning development time estimates.
4. Courage
Some XP practices are so unconventional that they require courage and constant self-control.5. Respect
Respect in XP means respecting the team and self-respect. Team members should not make changes that break the compilation, module tests, or slow down colleagues’ work. Each member strives for the highest code and design quality.
Implementing XP and the Workflow
Kent Beck recommends implementing XP to solve project issues. The team selects the most urgent problem and solves it using one of the XP practices. Then, they move on to the next problem, using another practice. This approach ensures that problems motivate XP adoption, and the team gradually masters all methodology tools.
To implement XP in an existing project, gradually adopt its practices in the following areas:
- Testing: The team creates tests before writing new code and gradually refactors old code.
- Design: The team continuously refactors old code, typically before adding new functionality.
- Planning: The team must closely interact with the customer.
- Management: Managers ensure all team members follow the new rules.
- Development: Start by organizing workstations for pair programming and encourage pairs to program most of the time.
Example of a Workflow Using XP
Who Uses XP
According to a 2016 VersionOne survey, only 1% of agile companies use XP in its pure form. Another 10% use a hybrid of Scrum and XP.While XP is not the most common methodology, its practices are used by most companies employing agile methodologies. For instance, Pivotal Software, Inc. attributes its success to XP.
Pivotal Software, Inc.
Pivotal Software, Inc. develops business analytics based on big data and provides consulting services. Their products are used by corporations like Ford, Mercedes, BMW, GAP, Humana, major banks, government agencies, and insurance companies.
Pivotal advocates agile methodologies as essential for modern development. Among the agile variants, they chose XP, a win-win approach for customers and programming teams. Their workday starts with stand-up meetings and ends at 6:00 PM — no overtime. Pivotal uses planning games, pair programming, constant testing, continuous integration, and other XP practices.
What to Read to Understand XP
- “Extreme Programming Explained,” “Planning Extreme Programming,” “Test-Driven Development” by Kent Beck: These books by the creator of XP provide an in-depth understanding of the methodology and its advantages.
- “Refactoring: Improving the Design of Existing Code” by Martin Fowler: A book by an XP co-author explaining the principles and techniques of refactoring.
- “Extreme Programming Applied: Playing to Win” by Ken Auer and Roy Miller: A practical guide to XP practices with examples.
Tools for Implementing XP in Teams
Redmine
A free, open-source task manager with features like multiple project support, flexible task management, Gantt charts, time tracking, documentation management, and task creation via email.
Basecamp
A simple, user-friendly service for collaborative project work, including a task manager, message boards, built-in chat, file storage, and calendar.
Jira
A robust service designed for agile project developers, combining a bug tracker and project management tool with many features and synchronization options.
Worksection
A secure service for project work, allowing task setting and process control, correspondence tracking, filter customization, time and financial tracking, and file management.
Conclusion
Extreme Programming is an agile methodology focused on producing high-quality, functional code with a simple architecture. Its purpose is to reduce uncertainty in projects and respond flexibly to changing product requirements.
XP is exclusively for software development and cannot be adapted to other businesses.
It is one of the most challenging methodologies to implement due to its thirteen practices. However, its practices are widely used in agile projects, proving their effectiveness.
The authors advise gradually mastering XP practices while solving project issues. If you see the benefits, continue in the same spirit. There is no obligation to implement XP on an all-or-nothing basis. After all, agile methodologies should be flexible in application — adapting to the needs of the specific project team.