Extreme Programming (XP) A complete guide for begginers.

How is it different from frameworks like Scrum? What Agile software development projects will it work in and what are the pros and cons of the Extreme Programming approach? Which engineering practices in XP are the key to success? Let’s find out!

Go To:

1. What is Extreme Programming (XP)?
2. The history of XP in software development
3. Extreme Programming vs other methods
4. XP vs Scrum
5. XP practices, values and principles
6. Extreme Programming Roles
7. Processes in Extreme Programming
8. Pros and Cons of Extreme Programming
9. In which teams will Extreme Programming work?
10. Summary

Extreme Programming Explained

Extreme Programming is an Agile project management framework. XP is based on values, principles and programming practices. Its main goal is to enable small and medium-sized Agile teams to deliver high-quality software, while adapting to changing customer requirements.
What distinguishes Extreme Programming from other agile approaches is the way it places emphasis on the technical aspects of software development. XP precisely defines the way developers work, which results in delivering high-quality software within the requisite period of time.
Simply put, Extreme Programming puts… extremely strong emphasis on good coding standards.

The history of XP in Agile software development

Extreme Programming dates back to the 1990s and was created by Kent Beck, also known as one of the 17 developers who signed the Agile Manifesto. It all started during a project which Kent Beck was involved in. In 3 years of project development, no major progress had been made, so Beck, who was new to team management, decided that teaching the team the techniques and practices that worked for him would be the best idea. Practices such as programming in pairs and TDD (Test-Driven Development) were successfully implemented. Based on this experience, in 1999 Kent Beck collated the practices, values and principles of Extreme Programming in his book “Extreme Programming Explained: Embrace Change”.

Extreme Programming methodology vs other methods

Waterfall approach	Extreme programming
Planning phase	Iteration Planning at the beginning of ech iteration (usually it takes only one week)
Programming phase	XP teams test software early – according to the test first programming approach
Testing phase	The code is written using Pair Programming techniques
Implementation	Work on small pieces of functionality and integrating then with other functionalities

How is XP different from traditional approaches? Extreme Programming is an Agile methodology, in which it is important to make changes smoothly. Instead of sticking to a specific, top-down plan, agile teams act flexibly.
Extreme Programming is very different from traditional methodologies, such as Waterfall.

XP vs Scrum

One might ask: all right, but doesn’t Scrum (which also focuses on incremental development) also offer all the above-mentioned possibilities?
Scrum is a framework that helps teams develop complex projects in an iterative way and does not impose strict rules as to how developers do their work. The main difference is that Extreme Programming, as previously mentioned, places strong emphasis on good coding practices.
In addition, it is directly related to programming, and Scrum can be applied to any project in which an iterative approach will work.

Extreme Programming is open to changes in its components (meetings, artifacts). Teams can and should adapt artifacts to their needs. On the other hand, the Scrum Guide states that “while implementing only parts of Scrum is possible, the result is not Scrum”. Scrum is a framework that needs to be complemented with one’s own processes and methodologies. This means that it is not only possible to use Extreme Programming and Scrum at the same time, but it even comes highly recommended.

Scrum

Short development cycles (1-2 weeks)
Focus on continuous delivery of small functionalities
Based on values: commitment, focus, courage, respect, openness
The product is at the center

Extreme Programming

Short development cycles (usually 1 week)
Focus on continuous provision of small functionalities with Test-Driven Development, Code Review, Pair Programming
Based on the values of simplicity, communication, feedback, commitment and respect
The product and developers are at the center
Responsibilities and artifacts can be adapted to the needs of the team

Extreme Programming practices, values and principles

Extreme Programming is based on values, practices and principles.

XP values

Values set a goal for a team. They work like a GPS that guides decisions at a high, abstract level. Due to the abstract nature of values and their genericity, it is difficult to obtain specific guidelines. For example, the claim that “communication is appreciated” can be understood vaguely (e.g. as dedicating Daily meetings to discussing only topics not related to the needs of the team and the client).

XP practices

They are, in a sense, the opposite of values. Values are general and theoretical concepts, while practices are the specific processes defining what needs to be done. Practices, therefore, help teams to keep values in mind. Example: Value – Communication. Practice – Knowledge transfer in a team.

XP rules

These are domain-specific guidelines that bridge the gap between practices and values.

Values and principles of Extreme Programming

Values

Extreme Programming values are: simplicity, communication, feedback, commitment and respect.

Simplicity

This can be described by the following sentence: “Do the simplest things that work”. However, this is often misunderstood, which leads to doing the simplest things such as changing style etc., and not those changes that provide real business value.
Keep in mind that simplicity in software development is a highly relative concept. Often what is simple for one team will be difficult for another. It all depends on skills, knowledge and experience.

Communication

Lack of communication prevents the flow of knowledge inside the team. Often, when a problem arises, one of the developers may already know how to solve it. However, the lack of communication prevents other people from knowing the problem or getting closer to solving it. It may turn out that several people try to tackle it simultaneously and independently, and this slows down the whole team.

Feedback

When using Extreme Programming, teams try to get feedback as early as possible and on a continuous basis. If there is a need for change, we, as programmers, want to know about it as soon as possible.
Feedback takes many forms and can vary in scope. When programming in pairs, comments from the other developer are direct feedback, as are the opinions of other team members – including the client, who is also a member of the team.

Tests are another source of valuable feedback. If writing tests is difficult and causes a lot of issues, it means that the architecture or solutions used in the project are too complicated and need to be simplified. It may turn out that a team receives more feedback than they can handle. Then there is a risk that in a number of cases, more important feedback will be omitted. You should then analyze why there is so much feedback and what needs to be changed.

Courage

Kent Beck defines courage as “effective action in the face of fear”. A software engineer has many reasons to be anxious, and at the same time many opportunities to demonstrate commitment.
Telling the truth, especially if it is unpleasant, for example about unrealistic estimates, requires courage. This is also the case when it comes to giving and receiving feedback.

Respect

The basic principle of Extreme Programming is that everyone cares about the quality of the code and engages in their work. Even the most state-of-the-art technological stack won’t save the project if there is no respect and care within.

Principles

The rules in Extreme Programming provide more detailed guidance than values. Principles explain values and make them clearer, eliminating unambiguity. For example, based on the value of courage, we could conclude that making a big change in the code is recommended. However, according to the principle of small steps, large changes are risky, so the changes introduced should be as small as possible.

People

Software is created by people for people. This is an obvious but often overlooked fact. However, taking the strengths, weaknesses and needs of a person into account is important, as it allows you to create products that people want to use. A work environment that gives opportunities for accomplishments and development, a sense of belonging, and space for work-life balance fostering a sustainable pace of work, is also a place where it is easier to take the needs of others into account.

Economy

XP teams are guided by economic factors when creating software, constantly assessing the risk and needs of the project. For example, User Stories shall be implemented first in terms of business value, and not in terms of technical issues.

Mutual benefit

In an XP project, you avoid solutions in which one side benefits at the other’s expense. For example, extensive documentation and specification can help someone to understand the issue, while pulling the team away from implementation and delaying it. A mutually beneficial solution is, for example, the use of automated acceptance tests. You get instant feedback on implementation, developers get precise code specifications, and users get faster access to functionality.

Similarity

If a solution works at a certain level, it can also work at a higher or lower one. For example, getting early and continuous feedback is important at different XP levels.
At the developer level – developers receive feedback from their code, using the Test First approach, consisting in writing unit tests before starting programming.
At the team level – the CI/CD pipeline tool builds and tests the code several times a day.
At the organization level – weekly and quarterly iterations allow teams to get feedback and improve work if necessary.
Improvement

In accordance with the principle of improvement, teams do not strive for perfection in the initial implementation phase, but for implementation that is good enough. They then continuously learn and improve the product thanks to feedback from users.

Diversity – developers benefit from a variety of approaches, skills and attitudes. However, such diversity often leads to conflict.
Conflicts and misunderstandings – when everyone is guided by the values of courage and respect, they have an opportunity to come up with better ideas. Courage is necessary to express a different opinion, and respect is needed to express it in an empathetic way. All this is an exercise in effective communication.
Reflection – teams reflect on their work and analyze how to improve. Extreme Programming creates many opportunities to do so, not only in weekly and quarterly cycles, but in every exercise.
Flow – Traditional methods have distinct phases that last a long time and leave little room for feedback and correcting things. Software development in XP takes place as part of continuous activities, with a consistent flow of value.
Opportunity – problems are inevitable in the software development process. However, every problem is an opportunity for improvement. It is worth looking at them as an opportunity to find a creative solution that will also prevent them from reoccurring in the future.
Redundancy – the principle of redundancy says that if a given problem is critical, we should use a variety of tactics to solve it. There is no one single tactic that can eliminate critical issues. Extreme Programming proposes to set several quality indicators. Pair Programming, tests, and continuous integration (CI) are helpful in achieving the intended quality.
Failure – it isnot in vain if you can learn from it. Making decisions and learning quickly what doesn’t work is much more productive than a lack of action caused by indecisiveness.
Quality – we often think that we have to choose between quality and speed. However, it is the other way round – the pursuit of quality improves the speed at which the team is able to work.
An example may be code refactoring, which facilitates understanding and changing the code. As a result, the likelihood of entering defects into the code is reduced, and it allows for faster delivery of greater value without the need to correct errors and understanding what the code is responsible for.
Small steps – baby steps – big changes are risky. Extreme Programming reduces this risk by making small step changes at all levels.

XP practitioners create code in small batches using TDD (Test-Driven Development). They combine their code with the code from the main branch several times a day, not just every few weeks or even every few months. The development of the project itself takes place in short iterations, not in long-term phases.

Accepting responsibility – in Extreme Programming, responsibility should be accepted, never assigned. It should go with deciding what we are responsible for. It also works the other way round. After all, we don’t want people to make decisions if they don’t have to deal with the consequences.

Streamline Your Application Maintenance

Leszek Jaros, our Head of Telco and AMS Practice, is here to help you navigate the complexities of Application Maintenance Services. Book a consultation to boost your application's efficiency

Schedule a meeting

Extreme Programming Roles

According to Kent Beck, an experienced, or mature, XP team should not rely on specific roles defined rigidly. Keep in mind that roles can be helpful for inexperienced teams. Over time, however, they may hinder effective cooperation.
Roles and responsibilities in the context of Extreme Programming:

The client

It would be best if there were a real customer / Product Owner on site to answer questions, prioritize user stories or collaborate on acceptance tests.

Developers

In XP teams, developers perform task delivery and history estimations, write tests and deal with implementation.

Trainer, Coach

It is not necessary to have a person in this role when using the XP approach. Such a role can be taken by a person who already has experience in Extreme Programming. The trainer’s task is to make sure that the team uses good practices, turning them into habits and not going back to the old ways of creating software.

Tracker

This is a person who tracks the progress of the team and talks to each developer. Consultations with each team member allow that person to identify blockers, bottlenecks and find ways to solve them. It is also the duty of the Tracker to present metrics showing how the team handles its velocity, and burndown charts. Often, in order to show such metrics, ready-made solutions, such as Scrum or Kanban boards, are used to automatically calculate statistics.

Processes in Extreme Programming

Extreme Programming includes 5 processes that are repeated iteratively:

Planning – the first stage when the client meets with the development team and presents requirements in the form of User Stories to describe the desired result. Then the team evaluates the stories and creates a release schedule divided into iterations needed to provide the required functionality, part by part. If some stories cannot be estimates, you can create “Spike” solutions, meaning that further research is needed, and often breaking down the task into even smaller user stories.
Designing – this is a part of the planning process. However, it can be moved to a separate process to highlight the importance of this step. This is related to one of the main XP values: simplicity. A good design introduces logic and structure into the system, avoiding unnecessary complexity and redundancy.
Implementation – this process consists in writing code using specific XP practices, such as set standards of code writing, Pair Programming or Continuous Integration.
Testing – the pillar of Extreme Programming. This is an activity that includes both unit tests, automated tests, and customer acceptance tests. Customer tests are performed to verify that the system meets the initial requirements.
Listening – includes ongoing communication and feedback. Clients and project managers engage in describing the business logic and its expected value for the business.

Advantages and disadvantages of Extreme Programming

Extreme Programming can be used in any software development project, but the positive and negative aspects of this approach and the differences between other agile frameworks should be considered.

Pros of Extreme Programming

Using XP can be beneficial and it helps to reduce the time and cost of software development:

Stability – thanks to refactoring and constant testing, we get a stable, well-functioning system.
Clean, concise code – it’s easy to read and amend in the future, if needed. The simplicity mentioned earlier on helps a great deal in this context.
Reduced documentation – extensive requirement files are replaced by user stories.
A result that meets expectations – the customer’s involvement in the development and testing process may directly affect the result. It is a guarantee that the business assumptions and requirements will be met, and the customer will get exactly what he or she needed.
No overtime – the maximum reduction or complete absence of overtime is possible thanks to short iterations that allow you to focus on specific requirements and deliver what the customer actually expects. The longer the iteration, the greater the risk that the requirements will not be properly understood and additional time will be needed to improve the solution that, for example, was created based on those parameters over several weeks.
Fewer errors – Pair Programming allows you to produce higher quality software that has fewer errors. At the same time, cooperation between developers can have a positive impact on understanding assumptions and certainty as to requirements.
Transparency – Continuous communication ensures a high level of transparency and accountability and allows the entire team to be up to date with progress and changes in the project.
Faster product delivery – a minimalist, iterative approach to software development translates into the fact that ready-to-use, usable components can be delivered very quickly. In addition, only the necessary functionalities will be implemented.

Cons of Extreme Programming

On the other hand, Extreme Programming has a number of disadvantages that you need to take into account when choosing this approach for your project:

Unclear final effect – during the project, the client very often does not yet have a clear picture of the final result. The lack of such a final vision makes it almost impossible to accurately estimate the scope of the required work, cost and time.
Unclear requirements – Documentation may be insufficient and may not contain clear and transparent requirements and specifications. This often leads to widening the project scope.
Greater impact of the human factor – Pair Programming requires more time and does not always bring the expected results. This may be due to personality mismatches.
Entry threshold – a quick shift from traditional software development methodologies to Extreme Programming calls for significant structural changes.
Limitations in terms of remote work – Extreme Programming works best for on-site teams and clients as it requires face-to-face meetings. This limits the use of XP in remote distributed teams.
More meetings – frequent meetings with customers usually take a lot of time, which could otherwise be used for proper implementation.
Stress – sometimes customers do not have the time, willingness or experience to participate in product development. Considering the urgent deadlines, it can generate stress – especially when the team does not receive valuable feedback or when a person with no or minimal knowledge of the processes tries to manage the developers.

In which teams will Extreme Programming work?

The functionality of the system they are working on will change every few months.
The requirements are constantly changing or you cooperate with a customer who does not know exactly what they expect from the system.
You want to reduce the risks associated with the project and avoid tight deadlines.
The development teams are small (preferably 2-12 people).
It is possible to closely cooperate with the customer.
There are options to use unit, automatic and functional tests.

To sum up: When use XP?

Extreme Programming will work well in software projects where customer requirements often change. This may involve more meetings, the need to engage the customer to get feedback, and to make changes to the team structure. However, if cooperation and continuous development are a priority for your team, it’s worth giving Extreme Programming a try.

This highly flexible approach is based on continuous feedback from customers, anticipates errors that may occur along the way, and includes the cooperation of developers due to programming in pairs. Extreme Programming not only ensures the delivery of a product that brings business value, but also increases the productivity of the development team.

Consult your project directly with a specialist

Book a meeting