What is Extreme Programming? Accelerate your Engineering Excellence!

What is XP?

Extreme Programming (XP) is an agile software development framework that mainly focuses on delivering better software while also improving the development team’s quality of life.

In terms of proper engineering methods for software development, XP is the most detailed of the agile frameworks.

When to use XP?

  • Lack of Communication is your primary failure
  • Want to improve your engineering practices
  • When you have so many software integration problems
  • Software requirements that are changing dynamically and continuously
  • Projects with a set deadline that leverage new technologies pose risks.
  • Extended development team with a small size or multiple-small size teams.
  • Unit and functional tests can be automated with the technologies you’re utilizing to build your products.

There are various scenarios where you may not wish to completely adopt XP due to its specialization when it comes to its full set of software engineering methods. When is XP Not Appropriate on the C2 Wiki is definitely a good place to start if you’re looking for examples of when you shouldn’t use XP. While you won’t be able to employ the complete XP framework in many cases, you should use as many of the practices as possible in order to accelerate business agility.


Communication, simplicity, feedback, courage, and respect are the five XP values, which are defined in more detail below.  


Inherently, software development is a team sport that relies on communication to communicate information from one team member to the rest of the team. XP emphasizes the importance of the right form of communication — face-to-face discussion using a white board or other drawing tool.


 “What is the simplest thing that will work?” is the definition of simplicity. The goal is to reduce waste and accomplish just what is absolutely necessary, such as keeping the system architecture as simple as possible to make it easier to maintain, support, and change. Simplicity also entails addressing only the requirements that you are aware of, rather than attempting to forecast the future.


Teams can find areas for development and update their procedures by receiving continual feedback on their previous efforts. Simple design is also supported by feedback. Your team creates something, collects input on the design and implementation, and then tweaks the product as needed.


Courage, according to Kent Beck, is “successful action in the face of dread” (Extreme Programming Explained P. 20). This definition demonstrates a preference for action based on other principles in order for the outcomes to be beneficial to the team. To bring up organizational challenges that are limiting your team’s effectiveness, you’ll need bravery. You must have the bravery to abandon something that isn’t working and attempt something new. Accepting and acting on feedback, especially when it is tough to accept, takes bravery.


To connect with one another, provide, and accept feedback that values your relationship, and work together to develop simple designs and solutions, members of your team must respect one another.


The interrelated collection of software development processes outlined below lies at the heart of XP. While some of these procedures can be done alone, many teams have discovered that some practices reinforce the others and should be used in tandem to completely minimize the risks that are common in software development. Since they were first established, the XP Practices have evolved slightly. Below is a list of the first twelve practices.

Visit  for additional information about how these approaches were first articulated.

  1. The Planning Game
  2. Small Releases
  3. Metaphor
  4. Simple Design
  5. Testing
  6. Refactoring
  7. Pair Programming
  8. Collective Ownership
  9. Continuous Integration
  10. 40-hour week
  11. On-site Customer
  12. Coding Standard

The practices discussed in the second edition of Extreme Programming Explained Embrace Change are listed below. These descriptions reflect a more practical set of techniques and incorporate adjustments based on the experiences of people who practice extreme programming.

Co-locate your team – Take a seat together, In COVID-19, create and embrace virtual face-to-face contact – don’t hide behind the screen. Nurture Virtual collaboration and improve teamwork.

Because one of the five XP values is communication, and most people think that face-to-face contact is the best, have your team sit together in the same space without any obstacles to communication, such as cubicle walls.

Whole Team – The Entire Group

A single team is formed by a cross-functional group of people who have the appropriate roles for a product. This means that people with a need, as well as everyone else involved in meeting that need, collaborate on a daily basis to achieve a specified goal.


Tip: cross-functional doesn’t mean jack of all trades and master of none. Cross-functional means team members bring multiple complementary skills to achieve product increment every iteration.

Educative Workplace

Set up your team space to encourage face-to-face conversation, provide some seclusion when needed, and make the team’s work visible to each other and interested parties outside the team. To actively disseminate up-to-date information, use meaningful Information Radiators.

Energized Work – Establish sustainable pace

When you are concentrated and free of distractions, you are most productive in software development and other knowledge work. Energized work entails taking actions to ensure that you are physically and psychologically capable of focusing. This implies that you should not overwork yourself (or let others overwork you). It also involves staying healthy and treating your teammates with respect in order to keep them healthy.

Pair programming

Pair programming refers to the development of all production software by two persons working at the same time on the same machine. This technique is based on the concept that having two brains and four eyes is preferable to having one brain and two eyes. You receive a continuous code review and a faster response to niggling issues that might stop one person in their tracks.

Teams that employ pair programming have discovered that it increases quality and does not take twice as long since they are able to solve problems faster and keep more focused on the task at hand, resulting in less code being written to accomplish the same goal.


We used to write requirements as “The system shall do …”, however at the end users told you that that’s what I wrote but that’s what not I need. So, why not write requirements in simple user language using plain simple English.

Describe what the product should do in ways that consumers and users will understand. These tales are meant to be brief descriptions of what users want to be able to do with the product that can be used for planning and as reminders for more in-depth discussions when the team comes around to implementing that story.

Tip: Yes, User Stories are not part of Scrum.

Tip: Anyone can write user stories, PO must agree/align on the acceptance of the story.

Tip: Not everything must be written in user stories format.


Weekly Cycle

Iteration is synonymous with the Weekly Cycle. In the case of XP, the team meets on the first day of the week to review progress, the client chooses the stories they want delivered that week, and the team decides how to approach those stories. The goal is to have running tested features that actualize the selected tales by the end of the week. The goal of the timed delivery period is to develop something that can be shown to the customer for feedback.

Quarterly Cycle

A release is synonymous with the Quarterly Cycle. The goal is to keep each weekly cycle’s detailed work in context with the broader project.

The customer lays out the overall plan for the team in terms of features desired within a given quarter, which gives the team a bird’s-eye view of the forest while they’re still in the trees, as well as assisting the customer in working with other stakeholders who may require an estimate of when features will be available.

When constructing a quarterly cycle, keep in mind that the information about any given story is at a high level, that the order in which tales are delivered within a Quarterly Cycle can change, and that the stories included in the Quarterly Cycle can change. Of course, if your plan doesn’t change, plow through the features planned in the release.

If you can reassess the plan on a weekly basis after each weekly cycle, you can keep everyone up to date as soon as changes occur, reducing the number of surprises.

Tip: It’s about being agile not doing agile.


Slack or Stretch goal


In XP words, slack is the addition of low-priority activities or stories to your weekly and quarterly cycles that can be abandoned if the team falls behind on more essential tasks or stories.

To put it another way, take into consideration the inherent uncertainty / variability in estimations to ensure that you have a decent possibility of hitting your targets.

Tip: Anyone asking for accurate estimate is “Oxymoron”


Build in Ten Minutes and every 10 minutes


The 10-Minute Construct’s goal is to build the entire system and run all of the tests in under ten minutes. The XP founders recommended a 10-minute time limit because if a team’s build takes longer than that, it’s less likely to be performed frequently, resulting in longer time between failures.

This technique encourages your team to automate your build process so that you’re more likely to execute it on a frequent basis and to run all of your tests through that automated build process.

This technique is supported by the practice of Test First Development and supports the practice of Continuous Integration.

Continuous Integration – It simply means – Integration that is ongoing

Continuous Integration is a method that involves testing code changes as soon as they are added to a bigger code base. This method has the advantage of catching and resolving integration difficulties sooner.

The code integration process is dreaded by most teams since it leads to the discovery of conflicts and difficulties. The majority of teams take the strategy of “avoid it as long as possible if it hurts.”

“If it hurts, do it more often,” say XP practitioners.

The logic behind this technique is that if you have problems every time you integrate code and it takes a long time to figure out where the issues are, you should integrate more frequently so that if there are issues, they will be much easier to detect because the build will have less changes.


Tip: The sooner you detect a problem, it will be lot cheaper to fix it earlier.


This method necessitates a higher level of commitment and is heavily reliant on Ten Minute Build and Test First Development.

Test-First Programming – TDD – Test Driven Development

Instead of following the normal path of:

develop code -> write tests -> run tests

The practice of Test-First Programming follows the path of:

Write failing automated test -> Run failing test -> develop code to make test pass -> run test -> repeat

Write a failed automated test, run it, then develop code to pass the test, run it again, and so on. Test-First Programming, like Continuous Integration, shortens the feedback loop for developers to find and resolve issues, reducing the number of bugs introduced into production.

Incremental Design – Designing in Small Steps

Incremental Design advises that you perform a little work up front to understand the correct breadth-wise view of the system design, and then delve into the minutiae of a single component of that design when delivering individual features. This method lowers the cost of revisions while also allowing you to make design decisions based on the most up-to-date information.

Tip: Refactoring was formerly mentioned as one of the 12 fundamental practices; however, it was later merged into Incremental Design.

Refactoring is a great way to keep your design simple, and one of the most common purposes of refactoring is to eliminate process duplication and reduce amount of rework.

References and Further reading:

Upcoming Blog will cover following topics:

DevOps, Release Planning

This website uses cookies and asks your personal data to enhance your browsing experience.