AGILE METHOD: EXTREME PROGRAMMING (XP)¶

Extreme programming is a discipline of agile software development that accords low significance to formal processes. It takes an incremental approach to achieving customer requirements. XP 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 approach is based on the values of simplicity, communication, feedback, courage and respect. In addition to the five values, XP also has principles and practices, which are also found in Kanban - although formulated differently.

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

Extreme programming project map¶

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 practicing 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 recognised 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 increment the content of the next increment is discussed and planned by all project team members, including the customer or its representative (internal project manager).

Short releases
The development cycles for new releases should be short, e.g. daily. This gives the customer fast access to new or changed functions. Also, the customer can provide prompt feedback to the development team so that they are quickly aware of any flaws in the system.

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 the parts of the code. They are collectively responsible for the code as a team.

Metaphor
The system metaphor is a story that everyone can tell about how the system works. All project team members should be clear about how the system works.

Sustainable pace
The concept is that programmers shouldn't work more than a 40 hour week, and if there is overtime in one week, the next week should not include more overtime. People perform best and most creatively 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
Automated component tests are performed on the source code to validate it. The user checks whether requirements have been met in acceptance tests.

Extreme programming life cycle¶

Creating value with XP¶

The life cycle of extreme programming is best described in terms of the weekly and quarterly cycles.

At the beginning, the customer defines a set of user stories whose size is estimated by the development team (see agile estimation). 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 boxed analyses of these stories and can take place before the start of an iteration or in parallel to 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 with the customer and decides which stories will be worked on. These are then broken down into tasks and implemented within the upcoming cycle.

Between the cycles (usually on weekends) the progress is reviewed by the team and the client. A decision is made whether the project should continue or whether enough value has already been delivered to close the project [65].

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¶