Extreme programming XP: Values, practices & rules guide
Summary
If the term extreme programming brings up images of action sports, you're not too far off. XP is a pretty extreme way of programming. Like other Agile methods, it uses adaptable, test-driven development. But unlike other methods, XP has strict rules and guiding values that govern how the work gets done.
What is extreme programming (XP)?
Extreme programming (XP) is an Agile software development methodology that emphasizes collaboration, customer involvement, and adaptability. It uses five guiding values, five rules, and 12 practices to deliver high-quality software through short development cycles and continuous feedback.
Like other Agile methods, XP breaks work into sprints and follows an iterative process. What sets XP apart is its discipline; frequent code reviews, unit testing, and collaborative teamwork are built into every stage.
Who created extreme programming?
The origins of XP date back to the late 1990s, when Kent Beck created it to manage the development of a payroll software system for Chrysler called the C3 project. The goal of XP was (and still is) to remove resistance to code changes within development projects. With XP, you scrutinize the code so carefully that developers may decide to rewrite it entirely after a single iteration.
5 values of extreme programming
Extreme programming is value-driven. Instead of relying on external motivators, XP allows your team to work more simply, focusing on simplicity and collaboration over complex designs.
1. Simplicity
Before starting any extreme programming work, first ask yourself: What is the simplest thing that also works? The "that works" part is a key differentiator; the simplest thing is not always practical or effective. In XP, your focus is on getting the most important work done first.
2. Communication
XP relies on quick reactivity and effective communication. The team needs to be open and honest with one another. When problems arise, you're expected to speak up because other team members will often already have a solution.
3. Feedback
Like other Agile methodologies, XP incorporates user stories and feedback directly into the process. Developers are in almost constant contact with customers, launching frequent releases to gain insights early and often. When you receive feedback, you adapt the process to incorporate it rather than overhauling the entire project.
4. Courage
XP requires a certain amount of courage. You're always expected to give honest updates on your progress, which can feel vulnerable. If you miss a deadline, you hold yourself accountable and get back to work.
If you're a team lead, your responsibility is to set the expectation for success and define "done" upfront. Things won't always go as planned, but when they change, your team is expected to adapt and move forward.
5. Respect
Considering how highly XP prioritizes communication and honesty, it makes sense that respect would be important. For teams to communicate and collaborate effectively, they need to be able to disagree kindly. Respect is a good foundation that leads to kindness and trust, even in the presence of a whole lot of honesty.
For extreme programming, the expectations are:
Mutual respect between customers and the development team.
Mutual respect between team members.
A recognition that everyone on the team brings something valuable to the project.
What are the 12 extreme programming practices?
To further hone the process, XP also uses a set of 12 practices. They are based on the Agile manifesto, but adapted to fit XP needs:
The planning game: XP planning guides the work. The results of planning should include what you're hoping to accomplish, by when, and what you'll do next.
Customer tests: After you finish a new feature, the customer will write an acceptance test to determine how closely it matches their original user story.
Small releases: XP uses small, routine releases to gain insights throughout the process. Often, releases go straight to the customers, though they can happen in-house.
Simple design: The XP system is designed for simplicity; you'll produce only what is necessary and nothing more.
Pair programming: All programming is done by a pair of developers who sit side by side. There is no solo work in extreme programming.
Test-driven development (TDD): XP's reliance on feedback requires heavy testing. Through short cycles, programmers release automated tests and then immediately react.
Refactoring: This is where you'll pay attention to the finer details of the codebase, removing duplicates and making sure that the code is cohesive.
Collective ownership: Any coding pair can change the code at any time, whether or not they developed it. Everyone's work is held to higher collective standards.
Continuous integration: XP teams don't wait for completed iterations; they integrate constantly. Often, an XP team will integrate multiple times a day.
Sustainable pace: Teams should decide how much work they can produce per day and per week, and use that to set realistic deadlines.
Metaphor: A shared story that uses language to describe how the team should function. For example, we're ants working collectively to build the anthill.
Coding standard: XP teams follow one standard. XP developers code in the same, unified way so that it reads as if it were written by a single developer.
5 rules of the extreme programming methodology
The values of extreme programming are more philosophical. The rules, on the other hand, are the practical means by which the work gets done. You'll need both to run an effective XP team.
1. Planning
In the planning stages of XP, you're determining if the project is viable and the best fit for XP. To do this, you'll look at:
User stories to assess whether they match the simplicity value and to check that the customer is available for the process.
The business value and priority of the project are to ensure this aligns with "getting the most important work done first."
What stage of development are you in? XP is best for early-stage development, and won't work as well for later iterations.
Once you've confirmed the project is viable for XP, create a release schedule. Keep in mind that you should release early and often to gather feedback. To do this:
Break the project into iterations and create a plan for each.
Set realistic deadlines and a sustainable pace.
Sharing updates as they happen empowers your team to be honest and transparent.
Share real-time updates that help the team identify, adapt, and make changes more quickly.
Use a project management tool to create a Kanban board or timeline to track your progress in real-time.
2. Managing
One of the key elements of XP is the physical space. XP purists recommend using an open workspace, with all team members working in one room. If you work on a remote team, consider using a platform that encourages asynchronous work for remote collaboration.
As in other Agile methods, use daily standups to encourage constant, open communication. XP also uses two planning cycles:
Quarterly cycle: Review user stories that will guide your work and study your XP process for gaps or improvement opportunities.
Weekly cycle: Start each week with a customer meeting where they choose the user story for programmers to tackle.
As a manager or team lead, your focus areas include:
Maintaining work progress and measuring pace
Shifting team members to address bugs or issues as they arise
Adapting the XP process to fit your current project and iteration
Remember, the goal of XP is to be flexible and complete work. Your work should be highly focused on the team's current priorities and reactive to changes.
3. Designing
When you're just starting out with extreme programming, begin with the simplest possible design. Later iterations will make them more complex. Do not add early functionality at this stage to keep it as bare-bones as possible.
XP methodology teams will often use class-responsibility-collaboration (CRC) cards to show how each object in the design interacts. CRC cards include:
Class (collection of similar objects)
Responsibilities (related to the class)
Collaborators (class that interacts with this one)
CRCs are useful for spotting potential problems early. Regardless of how you design, use a system that reduces bottlenecks by looking ahead for risks. When a potential threat emerges, assign one to two team members to develop a solution.
4. Coding
One of the more unique aspects of XP is that you'll stay in constant contact with the customer throughout the coding process. This partnership allows you to test and incorporate feedback into each iteration, rather than waiting until the end of a sprint. Coding rules are fairly strict in XP:
All code must meet coding standards.
Using a unit test to nail down requirements and develop all aspects of the project.
Programming as a pair, where two developers work together simultaneously on the same computer.
Use continuous integrations to add new code and immediately test it.
Only one pair can update code at any given time to reduce errors.
Collective code ownership, where any member of the team can change the code at any time.
5. Testing
You should be testing throughout the extreme programming process. All code must pass unit tests before it's released. If you discover bugs during these tests, you'll create new, additional tests to fix them.
Later on, you'll configure the same user story you've been working on into an acceptance test. During this test, the customer reviews the results to see how well you translated the user story into the product.
When should you use extreme programming?
Because extreme programming focuses on software development, it's typically only used by engineering teams. Even in software teams, it only works in certain settings. To get the most value out of extreme programming, it's best to use it when you:
Manage a smaller team. Because of its highly collaborative nature, XP works best on smaller teams of under 10 people.
Are in constant contact with your customers. XP incorporates customer requirements throughout the development process, and even relies on them for testing and approval.
Have an adaptable team that can embrace change. Extreme programming will often require your whole team to toss out their hard work and start fresh.
Are well-versed in the technical aspects of coding. XP isn't for beginners. You need to be able to work and make changes quickly.
Extreme programming vs. Scrum
Scrum and XP are both Agile methodologies, but they differ in focus and flexibility. Here's how they compare:
Aspect | Extreme Programming (XP) | Scrum |
Focus | Engineering practices | Project management framework |
Prescriptiveness | Strict rules and guidelines | Flexible framework |
Technical practices | Prescribes pair programming, TDD, continuous integration | Does not dictate technical practices |
Customer involvement | Constant contact required | Involved at sprint reviews |
Use cases | Software development only | Any iterative process |
Managed by | The team collectively |
Many teams find success combining both approaches, using Scrum's project management structure alongside XP's engineering discipline.
Benefits of extreme programming
By focusing on technical excellence and collaboration, extreme programming offers several key benefits for development teams:
Higher-quality software. Practices like test-driven development and pair programming help catch defects early, resulting in cleaner, more reliable code.
Greater responsiveness to change. The emphasis on small, frequent releases means you can adapt quickly to customer feedback and evolving requirements.
Improved customer alignment. Continuous customer involvement ensures the final product matches user expectations and business needs.
Sustainable development pace. XP's focus on a sustainable pace helps prevent burnout while maintaining consistent productivity.
Better team collaboration. Practices like collective code ownership and pair programming foster knowledge sharing and reduce silos within the team.
Challenges of implementing extreme programming
While powerful, XP is not without its challenges. Understanding these potential obstacles can help you determine if XP is the right fit for your team:
High discipline required. The methodology demands strict adherence to practices like TDD and pair programming. Teams without strong commitment often struggle to maintain consistency.
Customer availability. XP depends on having a dedicated and available customer representative who can provide ongoing feedback and make decisions.
Limited documentation. Some teams, especially those in highly regulated industries, may find the lack of detailed upfront documentation challenging.
Team resistance. Practices like pair programming and collective code ownership require developers to work differently than they might be accustomed to.
Scaling difficulties. XP works best with smaller teams. As team size grows, maintaining close collaboration becomes increasingly difficult.
Get started with extreme programming
At this point, you've likely gathered that extreme programming is, well, extreme. The process is rigorous and highly structured, but the results might be worth it. XP's unique development process, incorporating customer feedback and intense, collaborative programming, results in high-quality software.
Streamline your XP planning and management with a work management tool that updates and adapts in real-time, just as your work does. Get started with Asana today.
Probeer Asana gratis
