eXtreme Programming (or XP) is a project management method that applies the Agile development methodology to the eXtreme, which means focusing on the customers needs, implementing iterative development and continuous integration. The project team and its relationship with the client are at the heart of XP. 

This method was created by Kent Beck between 1996 and 1999, when he was working on a project for Chrysler. Originally developed for the IT sector, the eXtreme Programming method is very popular today because it works for all types of projects, of all sizes and in all sectors, all over the world.

A – Principle and Values

> The eXtreme Programming method is based on:

> XP is more than just a series of steps to manage projects—it follows a set of values that will help the project team to work faster and collaborate more effectively.

# 1 Communication: it is essential that each member of the team communicates daily with his colleagues as well as with the client. Any concerns or problems are addressed immediately.

# 2 Simplicity: the easiest way to achieve the result is preferred. The project team does what is necessary and requested, nothing more. XP breaks down each step of a major process into smaller, achievable goals for team members to accomplish. We use Stories, Design Thinking and dynamic prototyping instead of pages and pages of requirements.

# 3 Feedback: Feedback between the project team and the client is essential. In XP, teams adapt their process to the project and customer needs, not the other way around. The team should demonstrate their software early and often so they can gather feedback from the customer and make the necessary changes. Each modification request is taken into account immediately.

# 4 Respect: Extreme programming encourages an “all for one and one for all” mentality. Each person on the team, regardless of hierarchy, is respected for their contributions. The team respects the opinions of the customers and vice versa.

# 5 Courage : It takes courage to make certain changes like trying a new technique, restarting an unapproved iteration, or reviewing the organization of the project. Team members adapt to changes as they arise and take responsibility for their work. They tell the truth about their progress—there are no “white lies” or excuses for failure to make people feel better. There’s no reason to fear because no one ever works alone.

B – Operational XP: The 13 practices

The five values ​​of XP are broken down into thirteen practices mutually reinforcing:

#Client on site: the customer must be represented on site throughout the duration of the project. This representative must have a global vision of the result to be obtained and be available to answer questions from the team.

#Planning poker: the planning is done in collaboration with the client. He creates scenarios for the functionalities he wishes to obtain. The team assesses the time needed to implement them. The customer then selects the scenarios (or User Stories) according to the priorities and the time available.

# Continuous integration: when a task is completed, it is immediately integrated into the final product. This is to avoid the work overload due to the integration of all elements before delivery. The tests facilitate this integration: when all the tests are positive, the iteration is finished.

#Small deliveries: deliveries must be as frequent as possible so that the customer gives his opinion and the changes are quickly taken into account by the team.

#Sustainable pace: no overtime is tolerated. If there is, then the schedule should be reviewed. A tired team member works poorly and makes more mistakes.

#Functional tests: from the scenarios defined by the customer, the team creates test procedures which allow to check the progress of the development. When all functional tests pass, the iteration is complete.

#Unit tests: for each feature, a test is planned to verify that it will work as expected. This test will be kept until the end of the project, as long as the functionality is required. Each time the code is modified, all the tests are run in order to immediately identify if there is an operating problem.

#Simple design: we go straight to the point by focusing only on the customer’s current needs. The simpler the application, the easier it will be to evolve it in the next iterations.

#Use of metaphors: XP teams use metaphors to describe the system and how it works in order to clarify the functionality to be achieved. Everyone speaks the same language.

#Refactoring (or reworking of the project): the product is improved regularly. The goal is to have a good foundation and better working conditions for the team.

#Collective ownership of the project: the responsibility for the project is collective. Each team member can edit all parts of it, even those they haven’t worked on. The goal is to be efficient and fast.

#Language standards: since everyone is working together on the project, it is essential to facilitate everyone’s work by using the same terms, the same style and clear communication rules.

#Pair programming: team members always work in pairs. The pilot and the co-pilot change regularly in order to improve communication and collective knowledge of the project.

C – Production cycles

Projects managed by the eXtreme Programming method are based on short and fast development cycles (iterations) which are carried out collectively by the project team and the client, whose involvement is constant.

Counterproductive activities have been removed in order to reduce costs and frustration for all people involved.

D – In conclusion

With eXtreme Programming, managers, project team members and client work in collaboration. This approach favors the simplest method, promotes the responsiveness of the team and establishes continuous quality control.

Concretely, the XP methodology requires a lot of discipline and communication. You have to go fast, without losing sight and precision to focus on the final functions of the project. The great strength of the eXtreme Programming method lies in its simplicity and the fact that we go straight to the essential, following a rhythm that must remain constant to guarantee the best costs, without neglecting quality and deadlines.