Key takeaways
Extreme programming (XP) is one of those agile systems you’ve heard all about. It’s both a project management methodology and a software development practice simultaneously. A given implementation of XP will dictate both how the programming work is managed, and how the work is done.
When used effectively, it can help even small dev teams produce premium-quality software, satisfy user demands, meet difficult deadlines, and eliminate the need for dev team crunch, all at once.
“XP is a lightweight methodology for small- to medium-sized teams developing software in the face of vague or rapidly changing requirements,” is how its creator, Kent Beck, explains the concept.
Now, here are the highlights, and the ones that most programmers will agree on:
- XP is an agile framework, though the overlap between XP and its cousins is very minimal
- XP is a methodology that’s specific to software development, and many of its core tenets don’t translate well (or at all) to other fields of expertise
- The central objectives of XP are primarily focused on meeting the demands of users while maintaining high quality of life for development teams
- XP has a narrow range of optimal use cases, such as small development teams, tight deadlines, and strict quality requirements
Extreme programming in depth
Goals of XP
We’ve mentioned it above, but XP is distinct as a system even in what it’s attempting to accomplish. Scrum, for instance, is used to more efficiently manage labor and efforts, leading to the timely release of products and updates.
XP, on the other hand, focuses on producing a stable, functioning product that meets the user’s requirements, without running the dev team into the ground.
Core values of XP
Like so much in Agile systems, XP starts with its philosophy. Typically referred to as its core “values,” these outline what XP is trying to help teams achieve. Depending on who you ask, the values will come in a different order (if it’s hierarchical at all), omit a value, or otherwise make a modification to the concepts.
Most lists of XP values, however, contain the following five: simplicity, communication, feedback, courage, and respect.
Simplicity
This value is what the name implies: prioritizing simplicity in design, effort, and solution. The operative question is “What is the simplest answer that functions as intended?”
In order to adhere to this value, the implementation has to actually function, so “simplest” and “simple” may not be synonymous. But the edict to cut back on unnecessary complexity is still at the heart of it.
The spirit of this value can often be seen in video game design, when devs use existing parts of the build to enable something new toward the end of the project (e.g. “do we need to program the tram as a tram, or can we just make a tram-shaped hat for an invisible NPC that walks along the track?”)
Communication
If the objective is to deliver the desired user experience in the fewest steps possible, the team will need open lines of communication. With the user, with management, and with each other.
Communication in XP is expected to be rapid, transparent, and constructive. If devs encounter a problem, they share it with the team. If expectations change, they’re announced promptly. The faster questions, problems, concerns, or ideas are shared, the faster they can be addressed and the necessary adjustments made.
Feedback
Right along side of that is feedback. Constructive feedback, mind you. The goal is to make sure that the product that is delivered meets the needs of the user. One way this is achieved is by having constant contact with the customer, often by having them onsite.
Unlike scrum and kanban, where there are strict rules regarding how and when new priorities are added to the list, XP facilitates rapid pivoting based on near-instantaneous feedback. Essentially, the idea is that by reducing latency and increasing the frequency of feedback, projects can achieve their objective of simple yet functional solutions faster and with less wasted effort.
Courage
The above values only function properly when everyone involved in the process can approach things with a sufficient level of fearlessness. Feedback and criticism can be difficult to navigate at times. Admitting you have a problem you don’t know how to solve can likewise be intimidating. Mistakes, missed deadlines, and other “bad news” all tend to give team members pause.
XP requires the courage to push through that discomfort and do what’s necessary to recalibrate and get things back on the right track. That may mean throwing out a section of code that isn’t working, explaining that more time is needed, or a number of other things. It’s not fun, but that’s what it takes to achieve the objective without burning out the whole team.
Respect
Lastly, all of this communication, feedback, honesty, and focused collaboration depends on one final value: respect. XP is designed to ensure that the dev team’s time is respected. To establish that baseline, respect has to be shared all around. Feedback should be constructive, not critical.
Patience with errors, support for shortcomings, and an “everyone wins together” mindset are all central aspects of this value.
The rules of XP
In addition to the core values, which you’ll likely find common across the majority of XP discourse, some teams also espouse “rules” of XP.
The rules fall into five categories: planning, managing, designing, coding, and testing, and originally consisted of a list of 29 edicts. Since then, organizations have made modifications and adjustments to better suit their implementation, but the spirit of the rules remain the same.
Rules in XP function as the foundational implementation of the values, providing structure and strict guidelines regarding what success looks like, how it should be pursued, and what steps should be taken to address errors and setbacks.
Some of the most noteworthy rules include practices like pair programming, continuous integration, sustainable pace, establishing a system metaphor, and 40-hour work weeks.
The practices of XP
The real meat and potatoes of XP can be found in the “practices.” Unfortunately, this is also the area where the divergent descriptions of XP become the most prominent. Most resources you find or experts you ask will largely offer a consensus regarding the values. The rules will likely be familiar territory for them as well.
Once you get to the “practices,” things start to get very murky.
A lot of this comes down to how so much of the discussion uses the “rules” and “practices” interchangeably. Beyond that, the exact number will often vary between organizations, despite often being touted as if theirs is the canonical version.
Worst of all, sometimes the terms “methods” and “techniques” get thrown around, and applied in a synonymous or near-synonymous fashion.
That said, here are some of the most common and central “practices” that are in use for XP:
- Test-driven development
- Collective ownership
- Short iterations (one to two weeks)
- Small releases
- Onsite customer for rapid feedback
What is consistent across nearly every XP use case is the coding simplicity, the importance of rigorous testing and debugging, and the prioritization of a sustainable pace for development efforts.
Common Extreme Programming terms
Last but not least, let’s cover a few terms that are in large part unique to XP, and help illustrate the way this methodology differs from its peers.
Spike/architectural spike
When initially developing a new feature, or other portion of the software, teams will construct what’s referred to as a “spike.” The spike is the minimum amount of programming necessary to get the feature online and functional so that it can be tested for stability, debugged, compared against customer expectations, and more. In many ways, it’s similar to a Minimum Viable Product (MVP), but for portions of the whole.
System metaphor
To aid in clear communication, especially with non-technical stakeholders (like the customer, usually), teams running on XP develop a “system metaphor.” This is a comparative concept that can be used to conceptualize how the program is being built, even if the more technical aspects would otherwise be too complex to convey easily or quickly.
Some simple examples may be comparing the system to a city, a factory, a battleship, etc. The metaphor can be more fanciful, like a prominent pop culture reference. Or it may be more simplistic, like the list above. The key is establishing a common language that everyone understands inherently, including the non-devs and customers.
Pair programming
XP features an unusual tactic for accomplishing the work. Developers don’t code by themselves. There’s no solo work. Instead, devs are grouped in pairs, sitting side-by-side as they work on the code. The idea behind this is immediate feedback: two sets of eyes are more likely to catch and fix a bug as it’s being written. As they say, two heads, and all that.
Best and worst use cases for XP
XP can be effective, but it is, as the name might imply, rather rigorous. So it’s not a perfect fit for every team or every project.
Teams will likely see value in XP if:
- The team is small or mid-sized, often no more than 10 or 12
- Staff all do their best work in close proximity and with deep collaboration
- Project requirements are expected to change suddenly and frequently
- Rapid, continuous feedback is possible to achieve, even with the customer
- Timelines are tight, software volumes are high, and teams want to avoid overtime
Conversely, an alternative might be considered if teams are larger, timelines are further out, rapid feedback is difficult to achieve, staff are less experienced in coding, etc.
Extreme Programming (XP) background
Around the time that “online” started becoming a free-roaming adjective, and not just the middle letter of the AOL abbreviation, software teams started to realize they had a problem.
For decades,software, programs, and all other forms of computer code was produced the same way a house was built. There was a design and planning phase, resources were allocated, work was started, and specialized teams were only involved once the product reached the appropriate step in the process.
That programming methodology is usually referred to as “waterfall programming,” and it works fine when people are buying discrete apps (e.g. “Microsoft Office ‘95”). It’s not as conducive to incremental updates, “as-a-service” software models, or web-based platforms.
With market changes demanding a more continuous development mode, and non-dev administrators ill-equipped to provide a more feasible production system, devs got to work inventing their own. Borrowing from agile manufacturing philosophy, new paradigms began to be implemented to make life easier for the people who build the modern digital world.
Programming gets extreme
It wasn’t just user needs that drove the shift to new development systems, though. The increasing push to create more software—and do it faster—was demanding more and more from dev teams, and meeting those demands was rarely achievable with a normal 9-5 schedule. Staff was expected to invest increasingly more time and labor to achieve objectives.
Ask any programmer, and they’ll quickly tell you that producing software is a zero-sum game. The overhead can be cheap, the timeline can be fast, or the product can be good. At best, a team can pick two of the three: good and cheap, cheap and fast, or fast and good. And even when it looks like you’re hitting all three, there’s always a hidden cost somewhere.
In most cases, it was coming at the expense of the dev team’s quality of life. Harder work, longer hours, stricter requirements, all to hit deadlines that would only repeat in the next iterative cycle. As “crunch” became the name of the game, even the most tireless of code monkeys began to feel the burn.
Extreme problems and extreme solutions
Extreme programming represented an attempt to bridge the gap between the business of software and the building of software.
While other systems, like scrum and kanban, focused on coordinating teams, managing projects, and scheduling work, XP focused on what it saw as the two most important factors in development: the quality of the product, and the protection of the asset (i.e. development staff).
This is where XP separates from its other agile peers. While it features components of project management, much of the methodology is built around actual programming processes, outlining specifically how the code itself will be written from day-to-day.
Choosing the right project management software
Picking an agile framework isn’t necessarily easy. But it can save the team a lot of headache in the long run if you establish the right foundation for productivity in the beginning.
Maybe XP is the one that will serve your team best, but maybe not. Either way, if you find the framework you pick is sub-optimal, you can always iterate and try again with a new solution. After all, that’s the primary advantage of agile in the first place.
Looking for the latest in Project Management solutions? Check out our Project Management Software Buyer’s Guide.
Featured Partners: Project Management
Featured partners
