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.
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.
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.
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
The XP values: communication, simplicity, feedback, courage, and respect. Let’s look at each one of them in more detail.
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
Principles provide more specific guidance than values. They’re guidelines that illuminate the values and make them more explicit and less ambiguous.
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.
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.
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.
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.
How is XP Different From The Other Agile Methodologies?
Extreme programming, by nature, has a lot in common with the other agile methodologies but it’s also unique among them.
Most other development methodologies don’t say much, if anything at all, on how to do the work.. XP, on the other hand, is highly opinionated when it comes to that and puts great emphasis on software engineering practices.
Scrum is a framework for helping teams develop complex projects in an adaptive manner. Scrum doesn’t dictate how developers do the work. XP, as mentioned, puts much emphasis on good programming practices.
Also, XP is obviously about programming. Scrum, on the other hand, can be applied to any project that benefits from an iterative approach.
XP accepts changes to its components. Teams are allowed and even encouraged to tweak the practices according to their specific needs. The Scrum Guide, on the other hand, is adamant in stating that “While implementing only parts of Scrum is possible, the result is not Scrum.”
Also, Scrum is a framework that you need to fill out with methodologies and practices for doing the work.
That means that it’s not only possible to use XP and Scrum together but extremely recommended.
According to Kent Beck, a mature XP team shouldn’t rely on rigid roles, but recognize that roles can be useful for beginner teams, until they start to get in the way of collaboration.
That said, there are some common roles that people associate with XP:
Methods and techniques are the practices in XP. They fall into three main groups: software engineering, work environment, and project management.
Let’s start with the practices related to software engineering.
Pair Programming: In XP, you write code in pairs sitting at one machine. You and your pair talk to each other while analyzing, implementing, and testing the feature you’re working on. Pair programming is particularly effective in producing code with fewer defects while also being engaging, fun, and tiring.
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:
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.
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.
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.
The technical skills and habits of XP can be challenging to learn. Some of the practices can feel alien to programmers not used to them.
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!
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.