Skip to content

Extreme Programming

What is Extreme Programming?

Extreme Programming (XP) is a discipline of software development based on values of simplicity, communication, feedback, courage and respect. Extreme programmers constantly communicates with their customers and fellow programmers collecting feedback to drive the scope of the project with high flexibility. It is an agile software development framework that aims to product higher quality software while continuously fulfilling the customers’ and stakeholders’ needs.


The essence of XP is the interconnected set of software development practices. By applying these we can establish a basement for a successful agile process. The most important practices are the following:


The pair-programming sessions are one of core practices of XP. During this session the developers work in pair while focusing on solving the problem together, at one working station. One of the main benefits of pair-programming is that we introduce a peer-to-peer review with it, resulting in a more correct solution having less bugs. Next to that, by applying it we fulfill knowledge sharing responsibilities as well. In an agile time, it is very important to avoid having heroes and to sustain an environment where every team members are on the same level relating to the domain.

Test Driven Development

Test Driven Development (TDD) is one of the most famous design technique, having many benefits and advantages. TDD focuses on first having a test for a given high- or low-level use case, then at the second step on fulfilling the expected test verification. In other words, automated tests are written before any production code. At the third step, it emphasizes value on refactoring and cleaning up our code. Among many benefits, TDD shifts our focus from the implementation side to the client side, focusing on fulfilling the user needs and paying attention on edge cases and error scenarios. Furthermore, by practicing it, we introduce a safety-net protecting us from breaking our system. Last but not least, by using TDD we build a living low-level documentation which is the best place for usage examples of different system components. For more info about TDD, please visit my detailed post:

Continuous refactoring

Continuous refactoring is an excellent practice to keep the design clean, easier maintainable and extendable. The result is the so-called Clean Code and we should continuously pay attention and keep the code base as clean as possible. Furthermore, we should always keep up to date with the latest technologies and apply the best practices in order benefit from them both in the shorter and longer term.

Continuous integration

Apart from continuously keeping our code base clean and simple, we should also make sure that is is fully integrated according to our expectations, all the time. In practice it means that we have a automated Continuous Integration (CI) pipeline set up where the project is built and the corresponding unit and integration tests are run in an automated fashion, after every single commit of our source repository. This practice helps to raise awareness in case of introducing bugs and unexpected behaviors in our application.

Small and frequent releases

Next to the practice of continuous integration, we should also keep our new features and extensions deployed as frequent as possible in order to get valuable feedback from the customers and the users. This feedback is very important for driving the project scope according to the continuously changing customer requirements. To enable this, we apply Continuous Deployment pipelines with which we can easily roll out our latest solution to be used in the production environment.

Sit Together

XP bases a lot of value on communication where all the team members agree that the face to face communication is the most efficient form of communication. This practice also covers the “Individuals and interactions over processes and tool” concept of the Agile Manifesto. Therefore the team should sit in the same room, having meetings, conversation and discussions in the same space, face to face.

40-Hour Week

XP projects require healthy, rested and motivated developers in order to work fast, be efficient and to continuously maintain the product’s quality. It is essential to keep the work-life balance among the developers and to set up a proper environment for preventing professionals from burnout. Therefore the developers should work up to 40 hours and they should be never forced staying more in the office and doing overtime.

On-site customer

One important requirement of XP is to have a customer always available on site. It means that there is a dedicated customer a.k.a domain expert who is involved in the product development. In such way the intermediaries between the team of developers and the customer is eliminated, resulting in a faster and more efficient communication. There are different approaches, ones prefer having a business expert always assigned to the team, while others prefer working at a dedicated place at the customer head office, if it is possible.

Collective Ownership

Collective Ownership encourages everyone to take part of the project development proactively and to feel a shared responsibility for the project. It introduces democracy within the team and it prevents having heroes and bottlenecks in the team. Next to that, the responsibility of breaking the system is also shared therefore no individual can be blamed for mistakes and it must be a team issue and responsibility to fix it.

Simple Design

Simple Design is a methodology to keep things simple. It is originated from the design principle KISS (Keep It Simple, Stupid) from the U.S. Navy. The methodology aims at keeping the environment setups, the code bases and deployments simple and easily understandable. No over-engineering and no unnecessary complexities are appreciated and always the appropriate design patterns must be used and applied. As a result of it, we will end up with an easier understandable, maintainable and extendable environment and products.

Coding standards

In order to have an unified code base, we must set up a coding standards guideline beforehand, containing different kind of coding conventions such as formatting, naming and application protocols. Having and following such a guideline ensures that everybody produces code in the same form, resulting in a unified solutions accepted by all team members.


The Metpahor is aimed at improving the communication between the developers and the domain experts, resulting in a well-understood and well-developed domain model. It focuses on having an effective collaboration by using the same terms and labels by both the developers and the business people. Therefore it is essential to set up a shared and ubiquitous language in order to elaborate the domain model in an efficient and productive way and to minimize the misunderstandings.

XP vs Scrum

While there are many similarities and overlapping between the properties of Extreme Programming and Scrum, there are indeed some important differences. First of all, in XP the length of a development iteration is maximum up to 2 weeks, in contrast of 2-4 weeks within the Scrum framework. Next to that, Scrum does not allow to change and adjust the scope within an iteration, while XP has more room to change the scope according to the requirements and to unexpected issues. Furthermore, XP strongly encourages team to use the practices mentioned above, requiring strong engineering skills, while Scrum mandates planning ceremonies and artifacts. Relating to organizing and prioritizing works, in XP the developer team picks up the tasks based on priority defined by the customer, while in Scrum the tasks are prioritized by the Product Owner.


As you can see, XP strongly focuses on different kind of practicing resulting in a productive and flexible team. While there are many differences between XP and Scrum , the best is to combine both and apply most of the XP practices within the Scrum framework. Adding XP practices into Scrum can be greatly beneficial for any Scrum team, striving to be a more productive and professional team.

Published inAgile

Leave a Reply

Notify of