Skip to content

Theory "Agile Method Extreme Programming"

Extreme Programming, abbreviated XP, is a method that puts the solving of a programming task in the foreground and attaches little importance to a formalised procedure. With this method, one approaches customer requirements in small steps. It originated in the "Comprehensive Compensation System" project of the former Daimler Chrysler Group and is based on the application of proven methods (best practices). In this project, XP was developed as an agile process model for the creation of software.

This agile working method is based on the values of simplicity, communication, feedback, courage and respect. In addition to the five values, XP also has principles and practices that can also be found in Kanban - albeit formulated differently.

Similar to the Scrum framework, XP also has roles. These are the customer (client), the product owner (internal, often project manager) and the development team.

Framework conditions

Values

Extreme programming is based on five values that are intended to improve the work of the project team.

Communication

All team members should communicate verbally whenever possible. As a result, questions can be answered faster and more directly, and misunderstandings cleared up quicker.

Courage

Focusing on the values and practising open and direct communication embody courage. Continuous adaptation to changes and the reduction of customer requirements to the essentials can be challenging to people who aren't accustomed to upholding these values in projects.

Feedback

Fast, direct and continuous customer feedback improves the quality of the product. It ensures that flaws in the system are quickly recognized and recoded so that customer gets the product he needs.

Respect

The customer should respect the developers' know-how and vice-versa. Every member of the project team deserves to be respected and should, in turn, show respect.

Simplicity

Simple designs can be implemented faster than complex designs and they are often less expensive. That's why XP encourages starting with the simplest solution.

Principles

XP is based on principles derived from the values. The individual principles serve the basic understanding of XP.

Accepted responsibility

Responsibility is not delegated or assigned but accepted. As a result, each individual identifies more strongly with his or her function.

Assume simplicity

Simple designs can be implemented faster, at lower cost and are easier to understand and maintain. The lower the degree of complexity of a software, the easier it is to provide feedback.

Concrete experiments

Abstract decisions should be supported by a series of experiments to reduce potential risks.

Embracing change

The project team should unreservedly embrace change.

Honest measurement

Measurements are necessary to steer the project and gauge its progress. These measurements should be transparent, honest and comprehensible to all project participants.

Incremental change

Changes should be implemented incrementally, or in small steps. Then, they are easier to understand, less complex and involve less dependencies than complex changes.

Local adaptions

XP is adapted to local needs and requirements.

Open, honest communication

Project team members embrace honest, open and direct communication.

Play to win

These XP principles are designed to facilitate the success of the project. The developers don't simply want to produce perfect code, but a harmonious software package. Although this is a goal in other agile methods, XP in particular goes beyond the code.

Quality work

User feedback has a big impact on product quality. Objective (negative and positive) feedback is an important contributor to development team satisfaction. The development team should always be able to work in a framework that permits quality work.

Rapid feedback

The time between the activity and feedback on that activity is crucial. Feedback is another explicit element of quality assurance.

Small initial investment

By focussing on the important functions, the team can quickly develop the first viable prototypes.

Teach learning

Project team members have to learn what they need to achieve their goals, e.g. which and how many software tests the developers have to perform.

Travel light

The XP team has to get used to travelling light, which means using just a few tools, resources and methods. All they need are the tools that produce value for the project.

Work with people's instincts, not against them

Trust the team's instincts, even when it chooses an unconventional approach to achieving its goal. (Refer to the section on values and "respect".)

Practices

The values and principles are supplemented with practices. These practices help the developers to follow the principles.

Management practices

Onsite customer
A customer representative should be onsite to clarify requirements and questions directly. This function is often performed by the project manager.

Planning game
Before each iteration, the contents of the next iteration are discussed and planned with all project members, including the customer or its representative (internal project manager). The prerequisite for this is that it is known how long it took for user stories in the past to be implemented and that it is known how good the quality of the programmers' estimations is.

Short releases
New releases should be made at short intervals, e.g. daily. Customers thus receive fast and frequent access to new or changed functions. This enables the customer to give timely feedback to the development team and to quickly signal possible undesirable developments. In addition, short release cycles enable the customer to benefit as early as possible.

Team practices

Coding standards
Any developer can work on any piece of code. Team standards for coding should be established so that the entire team can share responsibility for the code.

Continuous integration
To avoid excessive dependencies and provide the customer with timely feedback, the change integration process is continuous.

Collective ownership
Any developer can work on any piece of code at any time. This means that all the programmers get to see all parts of the code. They are collectively responsible for the code as a team.

Metaphor
Few, clearly formulated metaphors should describe the system that has to be developed. The task of the system should be clear to all project members.

Sustainable pace
Programmers should not work more than the standard working hours. Overtime should be avoided or compensated by rest as soon as possible. Developers are creative and committed when they are rested.

Programming practices

Pair programming
All code is produced by two people programming on one task on one workstation. One programmer has control over the workstation and is thinking mostly about the coding in detail. The other programmer is more focused on the big picture, and is continually reviewing the code that is being produced by the first programmer. This approach helps to prevent source code errors and flaws in the system.

Refactoring
Refactoring is the process of restructuring the source code without changing its behaviour to improve non-functional attributes or reduce its complexity. Component tests prevent the occurrence of side effects.

Simple design
The less complex the system, the easier, faster and less expensive it is to implement. Other advantages are that the system is easier to maintain, understand, test and upgrade.

Testing
The source code is to be validated with automated component tests. The user checks the fulfilment of the requirements within the framework of acceptance tests, which serve to show the customer when the source code is executable and which tasks the developers still have to complete.

Extreme Programming (XP) Lifecycle

Creating value with XP

The life cycle of Extreme Programming is best described by the weekly and quarterly cycles.
At the beginning, a set of user stories is defined by the client and their size is estimated by the development team. Together with the relative benefit estimated by the customer, this results in a value that reflects the relative priority of the user stories.

If some user stories cannot be estimated by the developers due to unclear technical implementation, a "spike" is introduced instead. Spikes are more in-depth, time-limited analyses of these stories and can take place before the start of an iteration or in parallel with iterations that are already in progress.

Then the release plan is created. This plan includes all user stories that are to be delivered in a release or in a certain quarter.

Now the cycles can be started; they usually have a scope of one to two weeks. At the beginning of each cycle, the team meets the customer and decides which stories will be worked on. These are then divided into tasks and implemented within the upcoming cycle.

Between the cycles, and usually on weekends, a review of progress takes place between the team and the client. It is decided whether the project should be continued or whether enough value has already been delivered for the project to be completed.

Scrum vs. Extreme Programming

Distinguishing Scrum from Extreme Programming

Scrum is an agile project management method that doesn't dictate how a software project is implemented. Extreme Programming, on the other hand, is an agile software development method that covers the entire project lifecycle.

Differences

Scrum Extreme Programming
Developer typically work in iterations called Sprints that are between two and four weeks in length. Extreme programming iterations are generally one to two weeks in length.
Requirements do not change during a Sprint. If the XP team hasn't yet started working on a specific feature, it can swap it for another feature of the same size.
Scrum does not dictate how the project is to be implemented. Extreme programming involves test-driven development, automated tests, pair programming, refactoring, etc.