Extreme programming
XP starts from a provocative idea: if good engineering practices are valuable, why not take them "to the extreme"? If code review is good, program in pairs all the time. If testing is good, write the tests before the code. If integration is good, integrate several times a day.
Origin
Kent Beck developed XP while working on Chrysler's C3 payroll project in the late 1990s. He described it in Extreme Programming Explained: Embrace Change (2000), and it was one of the frameworks that most influenced the 2001 Agile Manifesto, of which Beck was a signatory.
The Five Values
XP is built on five core values:
- Simplicity: do only what is necessary and nothing more. Don't build for a hypothetical future.
- Communication: prefer direct, frequent conversation over formal documentation.
- Feedback: get rapid feedback on the code, the design, and the value delivered.
- Courage: make difficult decisions: refactor legacy code, discard work that adds no value, and estimate honestly.
- Respect: among team members and toward the customer.
XP practices
XP prescribes a set of specific technical practices that reinforce one another:
- Test-driven development (TDD): tests are written before the code.
- Pair programming: two developers work together on the same code.
- Refactoring: continuous improvement of the code's internal structure.
- Continuous integration: changes are integrated into the main branch several times a day.
- Collective code ownership: any team member can modify any part of the system.
- Coding standard: shared conventions that make the code readable for everyone.
- System metaphor: a shared vision of the architecture that uses a common language.
- 40-hour week: sustainable pace is part of the method; overtime is a symptom of a problem, not a solution.
- On-site customer: the customer or their representative is continuously available to answer questions.
- Small releases: frequent delivery of small, working increments.
- Planning game: the team estimates the effort and the customer sets the business priorities.
XP and AI as a Tool
XP's technical practices are especially relevant for teams that work with generative AI tools:
- TDD with coding assistants: teams that write the tests first and then let AI generate the code that passes them are consciously using XP to maintain the quality of the generated code.
- Collective ownership and AI code: in teams with coding assistants, collective ownership is still necessary: everyone must be able to understand, review, and modify the generated code, regardless of who (or what) produced it.
- Refactoring generated code: AI produces code that works but is not always well structured. XP's refactoring practice is the most direct tool for maintaining code health in teams that use generative AI.
Common mistake
Adopting XP practices without the values. XP practices work as a system: they reinforce one another. A team that does TDD out of obligation but without the value of "courage" (to refactor when needed) or "feedback" (to adapt the tests when the design changes) loses the benefits and accumulates technical debt in its tests. XP is not a list of techniques: it is a way of thinking about technical work.
References
- Beck, Kent. (2000). Extreme Programming Explained: Embrace Change. Addison-Wesley Professional.
See also
Want to advance in agility? You can search for course and exam calls, or go at your own pace by becoming a member of the Agile Club. This membership includes exclusive resources, e-learning classrooms, and access to Skill Arena: a space to practice and measure your agile skills at your own pace.