Extreme programming vs Agile methodologies

A lot of people working in the software industry today don’t remember the days when a development cycle could last anywhere from 18 months to three years. Aside from the wait time, the other problem was that goals were not consistently customer-driven, and so they didn’t always meet customer needs.

In the mid 90s the internet greatly changed how we do business. Companies needed to figure out how to streamline product development to shorten lead times and keep up with rapidly changing expectations, requirements, and needs.

This led software engineers like Kent Beck to find and define better ways to develop applications. Beck created extreme programming (commonly called XP) while working on a project for Chrysler in 1996. In February of 2001, Beck was an original member of “The Agile Alliance” of software developers who created the Manifesto for Agile Software Development—a document that outlines the key values and principles of incremental, feature-driven development.

In this article we’ll discuss the XP methodology and its relationship to Agile software development.

What is extreme programming?

Extreme programming is a software development framework that is focused on creating high-quality software quickly, directly tailored to customer requirements. The XP methodology supports frequent releases of usable software in short development cycles. 

Developing, testing, and releasing software in small, frequent increments creates checkpoints in the development process. These checkpoints make it easier for developers to evaluate their work and incorporate new customer requirements for subsequent releases.

You might think that this description of XP sounds a lot like Agile, and you would be right. That’s because XP is one of many methods under the umbrella of Agile principles used to develop software in short, incremental cycles. All of the Agile methodologies include practices and values that aim to improve software quality, release products quickly to market, and to be flexible and responsive to customer demands. But XP takes these practices and ramps them up to “extreme” levels.

Teams that need to quickly release software and respond to ever-changing customer needs, should take a look at XP to see if it is a good fit for their software development projects.

What is the difference between extreme programming and Agile methodologies?

Now that we’ve established that XP is one method in the Agile framework, it might seem silly to ask what the differences are between XP and agile. Instead, let’s ask what the difference is between XP and other agile methodologies.

One key difference might be the name itself. 

Let’s look at why it’s called “extreme” programming, and what makes it different from some of the other Agile practices.

• Code reviews are performed at every step, ensuring that code is clean and effective.
• Continuous regression testing ensures features and processes work correctly after changes are made to the code.
• Everybody does code refactoring every day to improve software design.
• Daily reuse of code improves design even more.
• Integration testing is performed several times a day to ensure that software modules work together in a group. 
• Most testing is automated so XP projects can be run and completed at top speed.
• Multiple short iterations make delivery more effective and provide opportunities to incorporate new requirements.
• Like other Agile methodologies, XP keeps the customer involved in the development process. But, XP doesn’t include any intermediaries between customers and the team.

Why use XP?

Extreme programming focuses on using frequent customer and stakeholder feedback. Teams work in fast, small increments, showing usable pieces to the customer. This gives programmers a good view into what is working well, what needs to be improved, and helps teams incorporate feedback quickly. 

XP teams believe that change is good, responding quickly to customer needs. This programming method encourages teams to work a small piece of the problem, then check its performance. That means that there is less waste, fewer major defects, and less rework. Ultimately, XP teams meet their customer needs faster, with cleaner code.

When should you use XP?

The extreme programming model is designed to improve  productivity by making teams adaptable, incorporating customer feedback, eliminating errors early, and encouraging collaborative coding.

Extreme programming might work well for teams that:

• Expect frequent functionality changes to systems and applications.
• Include only two to twelve software programmers.
• Want to reduce project risk.
• Can work directly with customers without an intermediary.
• Have customers who constantly change requirements or who don’t really know what they want yet.
• Can create automated unit and functional tests.

How does extreme programming work?

Extreme programming uses a set of values and rules that help development teams to work faster and more efficiently in a collaborative atmosphere. The values keep things simple and ensure consistency.

XP values

The following five values represent the foundation XP is built on. These values help team members to feel confident that the project is moving in the right direction and that everybody is on the same page.

Simplicity

Teams agree to work on and complete what is needed and asked for and nothing more. Large processes are broken down into smaller, achievable goals that can be accomplished quickly.

Communication

Teams work together in the same space and communicate face-to-face every day to ensure everybody understands the requirements and their assignments. This also ensures that problems are identified and addressed immediately.

Feedback

Teams adapt quickly to project changes. Software is demonstrated early and often to solicit feedback. They consider suggestions seriously and make the necessary changes. 

Respect

All members of the team are respected and contributions are valued—no matter how large or small. The team listens to and respects their customers and vice versa.

Courage

The team tells the truth about current progress and estimated completion dates. The team accepts responsibility for failure and does not offer excuses or try to place the blame somewhere else.

Rules of XP

We all need rules to function in society, and the same is true for extreme programming. The following rules remind the team about what and how things need to be done.

Planning

User stories are written to define the functionality the customer requires, the anticipated business value, and the feature priority. These stories provide just enough detail to help teams estimate how long it will take to implement the features. This information helps the team to create a realistic timeline with iterations for the project. 

Managing

Successful management of XP projects requires:

• An open workspace where team members sit together.
• Determining the right length for each iteration so you can set a sustainable pace.
• Daily standup meetings.
• Measuring how much work is getting done, known as project velocity.
• Moving people around and reassigning tasks as needed to avoid interruptions in the workflow.
• Adjusting if XP isn’t running as smoothly as you expected.

Designing

Extreme programming is based on the idea that you start with the simplest design that can possibly work. Then add complexity only when it's required. Choose a system metaphor so everybody understands the project through a common vision and a shared vocabulary. Refactor the code often to keep the design simple and to keep the code clean.

Coding

Now your team can start coding the project. To be successful, the team should:

• Always have the customer available, preferably on-site. This will keep communication lines open through all phases of the project.
• Write the code according to the standards everybody has agreed on. This keeps code consistent and makes it easier for the team to read and refactor.
• Create unit tests before you begin coding. This makes it easier to and faster to write your code later.
• Practice pair programming. Pair programming means that all code is created by two people at a single computer. This can increase the quality of the code without impacting the time to deliver. Only one pair integrates code at a time.
• Integrate and commit code several times a day to avoid fractured or diverging development efforts.

Testing

The team performs unit tests on all code and creates new tests when defects are found. The team also performs frequent acceptance tests and ensures that all bugs are fixed before the software is released.