Navigate to
What Is Extreme Programming (XP)? It's Values, Principles, And Practices
- 15 mins read
-
By
Marjan Venema
- Updated on February 19, 2024
Introduction to Extreme Programming (XP)
You’re familiar with agile methodologies, but Extreme Programming, XP for short, is still a bit of a mystery to you. It sounds, well, extreme, and you’re not sure that it’s for you.
Don’t let that name deter you, though. You’d miss out on a lot of good stuff.
This article will talk you through everything you need to know about extreme programming so you can put it to your advantage too.
Table of Contents
What Is Extreme Programming (XP)?
Extreme programming is a software development methodology that’s part of what’s collectively known as agile methodologies. XP is built upon values, principles, and practices, and its goal is to allow small to mid-sized teams to produce high-quality software and adapt to evolving and changing requirements.
What sets XP apart from the other agile methodologies is that XP emphasizes the technical aspects of software development. Extreme programming is precise about how engineers work since following engineering practices allows teams to deliver high-quality code at a sustainable pace.
Extreme programming is, in a nutshell, about good practices taken to an extreme. Since pair-programming is good, let’s do it all of the time. Since testing early is good, let’s test before the production code is even written.
A Brief History of Extreme Programming
XP’s origin dates back to the 90s when Kent Beck – who would later become one of the authors of the Agile Manifesto – created it when hired to lead Chrysler’s Comprehensive Compensation System team.
The project had started in 1993 and by 1996 hadn’t progressed much. Since Beck was new to managing a team, he decided the best course of action would be to teach his team members the techniques and practices that worked for him. They started applying practices such as pair programming and TDD with great success. Ron Jeffries — a friend of Beck and another author of the Agile Manifesto — was brought in to coach C3’s team.
In 1999, Kent Beck formalized the practices, principles, and values of XP in his book Extreme Programming Explained: Embrace Change.
How Does Extreme Programming (XP) Work?
XP, unlike other methodologies, is very opinionated when it comes to engineering practices.
Besides practices, XP is built upon values and principles.
Values provide purpose to teams. They act as a “north star” to guide your decisions in a high-level way. However, values are abstract and too fuzzy for specific guidance. For instance: saying that you value communication can result in many different outcomes.
Practices are, in some ways, the opposite of values. They’re concrete and down to earth, defining the specifics of what to do. Practices help teams hold themselves accountable to the values. For instance, the practice of Informative Workspaces favors transparent and simple communication.
Principles are domain-specific guidelines that bridge the gap between practices and values.
Image Src: LucidCharts
XP Values
Image Src: Alexsoft.com
Communication: Lack of communication prevents knowledge from flowing inside a team. Often, when there’s a problem, someone already knows how to solve it. But lack of communication prevents them from learning about the problem or contributing to its solution. So, the problem ends up being solved twice, generating waste.
Simplicity: Simplicity says you always strive to do the simplest thing that works. It’s often misunderstood and taken as the simplest thing, period, ignoring the “that works” part.
It’s also crucial to remember that simplicity is highly contextual. What’s simple for one team, is complex for another depending entirely on each team’s skills, experience, and knowledge.
Feedback: Feedback in more traditional, waterfall-like software development methodologies often is “too little, too late”.
XP, however, embraces change and XP teams strive to receive early, constant feedback. If there is a need to course-correct, XPers want to know that as soon as possible.
Image src: extremeprogramming.org
Feedback comes in many shapes and sizes. When you’re pair programming, the comments of your peer are vital feedback. So are the opinions from other team members about an idea, including the customer who, ideally, is a member of the team.
Tests are another source of precious feedback that go beyond the test results. Whether writing tests is easy or hard is feedback too. If you’re having a hard time writing tests, your design is probably too complex. Listen to the feedback and simplify your design.
Something that sounds like a great idea might not work that well in practice. So, finished code is also a source of feedback, as is a deployed product.
Finally, bear in mind that there’s such a thing as too much feedback. If a team generates more feedback than it can handle, important feedback may drop off the radar. It’s essential to then slow down and figure out what causes the feedback excess and fix it.
Courage: Kent Beck defines courage as “effective action in the face of fear.” As a software engineer, you have plenty to be afraid of and therefore plenty of opportunities to show courage.
It takes courage to speak the truth, especially unpleasant ones — for instance, honest estimates. Giving and receiving feedback also takes courage. And it takes courage to avoid falling into the sunk cost fallacy and discard a failing solution that received substantial investments.
Respect: A fundamental premise of XP is that everyone cares about their work. No amount of technical excellence can save a project if there’s no care and respect.
Every person is worthy of dignity and respect, and that includes, of course, the people affected by a software development project. When you and your team members respect and care about each other, the customer, the project, and its future users, everyone gains.
XP Principles
Image src: extremeprogramming.org
For instance, based on the value of courage alone, you could conclude that it’s advisable to tackle a big change at once in the program. However, the principle of Baby Steps tells us that big changes are risky. So, you want to favor tiny ones instead.
Humanity: Humans create software for humans, a fact that’s often overlooked. But taking human basic needs, strengths, and weaknesses into account creates products humans want to use. And a work environment that gives you the opportunity for accomplishment and growth, the feeling of belonging, and basic safety, is a place where you more easily take others’ needs into account.
Economics: In XP, teams heed the economic realities of software development all the time, they constantly assess the economic risks and needs of the project.
For instance, they’d implement user stories according to their business value rather than technical concerns.
Mutual Benefit: Following XP, you avoid solutions that benefit one party to the detriment of another. For instance, extensive specifications might help someone else understand it, but it takes you away from implementing it, and it delays it for your users.
A mutually beneficial solution is to use automated acceptance tests. You get immediate feedback on your implementation, your colleagues get precise specifications in code, and users get their features sooner. Plus, all of you get a safety net against regressions. Nimble Agile becomes the cornerstone of managing projects and teams by harmonizing these essential principles into a coherent and effective strategy.
Self-similarity: If a given solution works at a level, it might also work at a higher or lower level. For instance, obtaining early and constant feedback is at play at various levels in XP.
-
at the developer level, programmers receive feedback from their work using the test-first approach;
-
at the team level, the continuous integration pipeline integrates, builds, and tests the code several times a day;
-
at the organization level, the weekly and quarterly cycles allow teams to get feedback and improve their work as needed.
Improvement: According to the principle of improvement, teams don’t strive for perfection in an initial implementation but for a good enough one, and to then learn and improve it continuously with feedback from real users.
Diversity: You and your coworkers benefit from a diversity of perspectives, skills, and attitudes. Such diversity often leads to conflict, but that’s okay.
Conflict and disagreement are opportunities for better ideas to arise when everyone plays by the values of courage and respect. Courage to express opposing points of view, respect to expressing those in a civil and empathetic way. And all of this is an exercise in effective communication.
Reflection: Great teams reflect on their work and analyze how to be better. XP offers plenty of opportunities for that. Not just in its weekly and quarterly cycles, but in every practice it promotes.
Feelings are important to consider in addition to logical analysis. Your gut can inform you before you can reason about something. And so can talking to non-technical people, they can ask questions that open up entirely new possibilities.
Flow: Traditional software development methodologies have discrete phases, which last for a long time and have few feedback and course correction opportunities. Instead, software development in XP occurs in activities that happen all of the time, in a consistent “flow” of value.
Opportunity: Problems are inevitable in software development. However, every problem is an opportunity for improvement. Learn to look at them that way and you’re far more likely to come up with creative, goal-oriented solutions that also serve to prevent them from happening again.
Redundancy: The redundancy principle says that if a given problem is critical, you must employ many tactics to counter it.
Take defects. There isn’t a single tactic that can prevent all defects from escaping to production.
So XP’s solution is to stack a bunch of quality measures. Pair programming, tests, continuous integration. Each a single line of defense, together a virtually impenetrable wall.
Failure: Failure isn’t waste when it results in knowledge. Acting and quickly learning what doesn’t work is way more productive than inaction caused by indecision in choosing between many options.
Quality: Often people think there’s a dilemma between quality and speed.
It’s the opposite: pushing for quality improvements is what makes you go faster.
For instance, refactoring — changing the structure of the code without altering its behavior — is a practice that makes the code easier to understand and change. As a result, you become less likely to introduce defects to the code, which allows you to deliver more value sooner by not having to fix bugs.
Baby Steps: Big changes are risky. XP mitigates that risk by doing changes in tiny steps, at all levels.
Programmers write code in tiny steps using test-driven development. They integrate their code to the mainline several times a day, instead of only every few weeks or even months. The project itself occurs in short cycles rather than long-lasting phases.
Accepted Responsibility: In XP, responsibility should be accepted, never assigned.
Responsibility should be accompanied by the authority to make decisions on what you’re responsible for. The reverse also applies. You don’t want people making decisions if they don’t have to live with their consequences.
Similarities and Differentiators
How does XP differ from traditional, non-agile methodologies?
Extreme programming, being part of agile, it’s all about embracing and welcoming change rather than following rigid plans. It’s about iterative design rather than a big design upfront.
XP differs dramatically from traditional methodologies — i.e. waterfall — by avoiding long-lasting phases.
-
Instead of a planning phase, in XP you plan at the start of each development cycle which usually lasts just a week.
-
Instead of testing episodes, you test your application as soon as you can: that is before the actual code is implemented.
-
Instead of implementing features in isolation during long implementation phases and then struggling to merge your contributions to the main line, you work in small chunks and integrate those chunks as often as possible.
How is XP Different From The Other Agile Methodologies?
Extreme Programming vs. Scrum
Key Roles and Responsibilities
-
Customer: ideally, there should be a real customer on-site to answer questions, prioritize user stories or collaborate with acceptance testing. When this isn’t possible, this role could be fulfilled by a customer representative.
-
Programmers: in an XP team, programmers estimate the effort needed to complete tasks and stories, write automated tests, and implement the stories.
-
Coach: Having a coach isn’t required, and many teams have achieved success without one. However, having someone experienced in XP to coach a team can ensure the team members follow the practices, turn them into habits and don’t revert to the old ways.
-
Tracker: A tracker tracks the team’s progress metrics and talks with every team member to identify roadblocks and figure out solutions. The tracker calculates the metrics that indicate how well the team is doing, such as velocity and burndown charts, or the team uses a digital scrum or kanban board that calculates them automatically.
Methods and Techniques
Software Engineering
Ten Minute Build: The continuous integration server is expected to build the whole project — including running all the automated tests — in ten minutes at the most. This limit serves to keep tests lean and mean, i.e. focused.
Test-First Programming: In XP, you implement your features using the test-first approach, also called test-driven development (TDD.) TDD consists of developing using a straightforward cycle:
-
you write a failing test;
-
then, you write production code to make the test pass;
-
if needed, you refactor the production code to make it cleaner and easier to understand.
TDD brings several benefits to the table
First, feedback. If it’s hard to write a test, the design you’re going for or have inherited, is probably too complex, and you have to simplify it.
Second, TDD allows programmers to trust the code they write, and creates a nice, cyclical rhythm where the next step is always clear.
Last but not least, using TDD from the start ensures 100% code coverage. The test suite then truly becomes a safety net for future changes, encouraging code refactoring and creating a virtuous circle of quality.
Incremental Design: The practice of incremental design means that you must invest in the design of the application every day, searching for opportunities to remove duplication and make small improvements reaching the best possible design for what the system needs today.
Continuous Integration: In XP, you integrate your work to the shared main repository many times a day, triggering an automatic build of the whole system. Integrating as early and often as possible dramatically reduces the cost of the integration as it makes it less likely for merge and logical conflicts to occur. It also exposes environmental and dependency problems.
Shared Code (Collective Ownership): XP promotes shared code, or collective ownership: every developer is responsible for all of the code. It encourages an exchange of information, reduces the team’s bus factor, and increases the overall quality of each module if we consider the principle of diversity.
Single CodeBase: Single codebase is also known as “trunk-based development.” It means that there is only one single source of truth. So, rather than developing in isolation for long periods of time, you merge your contributions to the single stream early and frequently. Feature flags help to keep feature use restricted while they’re not complete.
Daily Deployment: Deploying to production at least once a day is a logical consequence of continuous integration:. Actually, nowadays, many teams go even further and practice continuous deployment. That is, every time someone merges to the mainline, the application is deployed to production.
Code and Tests: This practice means that source code – including tests – is the only permanent artifact of a software project. Putting effort into generating other types of artifacts, including documentation, is often waste because it doesn’t generate actual value for the customer.
If you need other artifacts or documents, strive to generate them from the production code and the tests.
Root-Cause Analysis: Whenever a defect slips into production, don’t just fix the defect. Ensure you understand what caused it in the first place, why you and your teammates couldn’t prevent the slip. Then, take steps to ensure that it won’t happen again.
Work Environment
Sit Together: In XP, teams favor working together in an open space. This practice favors communication and the sense of belonging in a team.
Whole Team: Everyone who’s needed for the success of the project is a part of the XP team. That is highly contextual — different for each team — and dynamic, it can change within a team.
Informative Workspaces: An informative workspace uses the team’s physical space to display information that lets anyone know, at a glance, the progress of the project. How that’s done might vary, from physical notes and charts to screens displaying Kanban boards and dashboards from a project management software.
Energized Work: In XP, you work only as long as you can do energized work. Work hours must be limited to 40 a week, at the most.
Project Management
Stories: You write user requirements in a format known as user stories. A user story has a short, descriptive name and also a brief description of what is to be implemented.
Slack: When planning for a cycle, add minor tasks the team can drop in case they need. More stories can always be added if the team over-delivers.
Cycles (Quarterly and Weekly): Development in XP happens in two main cycles: the weekly cycle and the quarterly cycle. More on that in the next section.
Key Meetings, Cycles, Delivery Cadences: Development in XP works in two primary cycles: the weekly cycle and the quarterly cycle. Initially, Kent Beck recommended a two-week cycle, but he changed this in the second edition of his book.
Weekly Cycle: The weekly cycle is the “pulse” of an XP project. The cycle starts with a meeting where the customer chooses which stories they want to implement during the week. Also, the team reviews their work, including last week’s progress, and thinks of how to improve their process.
Quarterly Cycle: Each quarter, the team reflects and identifies opportunities for improvement in their process. The customer picks one or more themes for that quarter, along with stories in these themes.
How To Get Started With XP?
To get started with XP, teams can adopt one primary practice at a time. To decide where to start, decide what’s the next goal you want to achieve. Pick the practice that aligns with that goal.
For instance, if your team needs to build a sense of trust, both in the code and in other team members, start with pair programming and TDD. If you need to eliminate the risk associated with relying too much on specific team members, adopt collective code ownership.
One question that is often on the minds of teams is the apparent cost of adopting XP practices – that is true only in the (very) short term, and the medium to long term benefits will far outweigh the costs!
Go eXtreme with XP — the Developers’ Agile
Most agile frameworks and methodologies focus on project or product management and organization of people and work.
XP is unique in how it shines a spotlight on good practices that other agile methodologies leave as an exercise for the user. That’s you.
It means XP is compatible with other methodologies and we dare to say adopting an agile framework without also using XP is suboptimal. That’s because without the practices to help you deliver value at a steady sustainable pace, your code will become less and less accommodating to change and you’ll eventually end up in a quagmire not amenable to change.
So go eXtreme and start adopting XP. It’s the developers’ agile that’ll keep everyone agile. Signup for a free trial of Nimble Agile and embrace Agile to help you gradually improve your processes.
Signup for updates!
Speed up your Agile planning and execution!
Signup for a FREE Trial of Nimble Agile
