Traditional project management approaches are not as viable as it was decades ago. Software engineering is a fast-paced environment, and IT professionals have to constantly discover new ways to handle frequently changing development tasks.

This idea was relevant 19 years ago when 17 software specialists introduced the Agile project management philosophy and described the famous Agile Manifesto.

The principles of fast and flexible software development were outlined in different methodologies. Extreme Programming (XP) was one of them. 

The key characteristic of Extreme Programming is the emphasis on technical aspects of software development. What are the main values and principles of this outstanding methodology? Spend 8-10 minutes to figure it out.

What is Extreme Programming?

Extreme Programming is an Agile software development framework that is aimed to produce software of higher quality with a higher quality of life for developers. This one is the most specific of Agile frameworks in terms of engineering practices.

What are the origins of XP?

In the 1990s, software development had two basic influences: 

  • Internal. Procedural programming was replaced by object-oriented programming.
  • External. Internet profusion emphasized company-growth and speed-to-market as competitive business factors. 

The requirements were rapidly changing, and that demanded shorter product life cycles. It was often incompatible with traditional software development methods.

Professional contributors discussed various ideas, and as a result, some additional methodologies were created. In order to get more facts about these methodologies, feel free to study our recent articles about Agile software development:

The method was first described by Ken Beck in the 90s. In 1999, the Extreme Programming approach was updated in the book “Extreme Programming Explained: Embrace Change.”

Extreme Programming book

XP was adopted in a number of environments. Nowadays, it has not stood still, as Agile software development practices are still evolving.

XP Purposes

Extreme Programming has the following five aims:

  • to strike a balance between humanity and productivity
  • to provide a mechanism for social change
  • to provide a way for improvement
  • to be a style of development
  • to improve software development discipline

The key goal of Extreme Programming is to lower the cost of change. 

Traditional software development methodologies determine the requirements for the system at the very beginning of the project. They are often fixed from that point on, and it means that the cost of changing requirements at a later stage will be high.

Extreme Programming is aimed to lower the cost of change by introducing its values, principles, and practices.

What are the Values of Extreme Programming?

Extreme Programming provides its admirers with five key values that form a special mindset of team players who try to perform effectively on the way to achieving a common goal. These values are:

  • Communication. Every team member works collaboratively with other people at every project’s stage.
  • Simplicity. When the development team writes simple code, it saves time and effort, bringing more value to the product.
  • Feedback. According to the methodology, the team delivers software frequently and get feedback, improving the product based on the new requirements.
  • Respect. Each individual assigned to a project contributes to a common goal.
  • Courage. Developers evaluate their own results objectively, and they are always ready to respond to changes.

The principles of Extreme Programming derive from these values and reflect them in detail.

What are the Key Principles of Extreme Programming?

  • Constant and rapid feedback. Everyone in the team gets feedback and reacts to it on time and in the right away.
  • Simplicity allows programmers to focus on the job that is important at the moment.
  • Incremental changes are added to a product step by step. Such changes have a better result than the big ones made at once.
  • Embracing changes. When customers think that the product should be changed, developers should agree and plan how to implement new requirements.
  • Qualitative work. Only a well-performing and effective team can make a valuable product and feel proud of it.

Extreme programming

Extreme Programming Roles

XP does not establish specific roles for team members though it specifies particular practices for the team to follow. There are four typical roles associated with the XP concept:

  • customer
  • developer
  • tracker
  • coach

Customer

A customer is responsible for all project decisions, including:

  • What should the system do?
  • How to know when the system is done?
  • What is the available funding?
  • What to do next?

XP customers are often actively engaged in the project; they become a part of the team.

Developer

Everyone in the XP team can be defined as a developer just because the methodology does not have much need for role definition. Developers are responsible for realizing the stories that are identified by customers. 

Tracker

Often a tracker is one of the developers who additionally covers this functionality. The main goal of this role is tracking relevant metrics that are necessary to monitor the team’s progress and to define spots for improvement. 

These metrics involve velocity and the reasons for its changing, the amount of overtime, and passing/failing tests.

Coach

The role of a coach is required if a team is just starting to apply the method. The coach is usually a consultant who has used XP before and may help the team to avoid possible mistakes.

He/she helps to mentor team members on the Extreme Programming practices and helps everyone to maintain self-discipline.

XP Practices

The Extreme Programming methodology includes the interconnected development practices that can be done in isolation. Many teams discovered that some practices reinforce the others, and in conjunction, they can eliminate development risks.

The original XP practices are:

XP 12 principles

The 2nd edition of “Extreme Programming Explained Embrace Change” (mentioned above) proposes the description of the practices with  essential refinements:

  • Sit Together. A face-to-face dialog is the best type of communication, that is why XP advocates should sit together in the same space without barriers. Cubicle walls seem quite a cozy solution.
  • Whole Team. Any team is composed of cross-functional specialists with their specific roles and duties. These people need to work together to deliver a particular outcome on a daily basis. 
  • Informative Workspace. It’s important to create a comfortable space to facilitate face-to-face communication as well as allow team members to have some privacy. Use possibilities of modern digital workspace to actively communicate relevant information.
  • Energized Work. When everyone in the team is focused and free from distractions, they perform more effectively, and all knowledge works better.  Energized work means making sure you can physically and mentally get into a focused state.
  • Pair Programming. Two brains are better than one. It means that two people sitting at the same machine develop all software collaboratively. Pair Programming improves quality and does not take twice as long as people are able to work through problems quickly.
  • Stories that describe what the product should do and the things users want to be able to do with this product.
  • Weekly Cycle. This is the same as the iteration. The XP team has a meeting on the first day of the week to reflect on progress. The customer chooses the stories he/she would like to deliver this week, and the team defines how they will approach those stories.
  • Quarterly Cycle is synonymous with a release. The goal is to keep the detailed work of every weekly cycle in the context of the entire project. 
  • Slack. This is about adding some tasks (or stories) with low priority in weekly and quarterly cycles that can be skipped if the team gets behind on more important tasks (or stories).
  • Ten-Minute Build. This approach means automatically building the whole system and running all of the tests in 10 minutes. When teams have a build that takes longer than 10 minutes, it is less likely to be run on a frequent basis. This introduces a longer time between errors.
  • Continuous Integration. This practice means that code changes are immediately tested when they are added to a larger codebase. It allows for catching and fixing integration issues sooner. 
  • Test-First Programming. It means following the path “write failing automated test > run failing test > develop code > run test > repeat”. The Test-First Programming approach reduces the feedback cycle for developers. It helps to identify and resolve issues, decreasing the number of bugs.
  • Incremental Design. This practice suggests that the team should work upfront to understand the proper perspective of the system design. The approach reduces the cost of changes and allows teams to make design decisions according to the most current data available.

Final thoughts

Why should you use XP? This Agile framework really helps software development teams to meet the requirements of customers who might not know exactly what they want or whose needs may change frequently. 

Extreme Programming mitigates the risks of managing projects thanks to the adaptation to constantly changing requirements. Just keep in mind that XP takes quite a small development team and close cooperation between managers and customers.