Extreme Programming (XP)
Having described the Waterfall Model, the idea of the Extreme Programming (XP) approach now follows. XP has been chosen here as an example because it describes the most extreme case of agile procedure methodology.
The roots of XP lie in Project C3 (Chrysler Consolidated Compensation) at DaimlerChrysler between the years 1997 and 1998 – an internal accounting system for employees. After the project threatened to fail, the company commissioned Kent Beck, Ron Jeffries, Martin Fowler and others to set it up from scratch – with success. Kent Beck summarized the ideas that formed into a method and published them in the book “Extreme Programming Explained – EMBRACE CHANGE”.
XP is a framework consisting of three main elements:
Diagram 5 from [Beck2004] outlines the framework conditions that Kent Beck links with the values, principles and practices.
Diagram 5: Outline of the Framework Conditions (Beck2004)
Values of XP
XP is based on four values:
- Simplicity: Simple solutions are cheaper and quicker to implement than complex solutions. Therefore, XP always tries to find the simplest solutions.
- Communication: All team members should communicate intensively with each other . Through personal dialogue, misunderstandings can be eliminated very quickly; questions can likewise be answered very promptly. As a result, documentation can sometimes be waived.
- Feedback: In order to achieve high quality, namely to achieve what the customer needs, very short feedback loops are used to show the development to the customer continuously. Thus, an incorrect development can be stopped very quickly. Feedback does not only come from the customer, but also from the tests.
- Courage: To use these values and at the same time communicate openly requires a great deal of courage, especially for those project members who are not used to acting in accordance with these values. It takes courage to scale the requirements of the customer down to the most important points with continuous feedback and openness as well as direct communication with the customer and other project members.
Principles of XP
XP is based on fifteen principles that can be derived from the four values. The individual points shown here are admittedly very brief, but a basic understanding of XP can still be formed.
- Rapid Feedback: Feedback on all activities should be sought as quickly as possible, resulting in good learning effects.
- Assume Simplicity: Simple solutions are easier to understand and feedback can be obtained faster.
- Incremental Change: Continuous small changes press ahead – major changes usually have many dependencies.
- Embracing Change: Being open to change.
- Quality Work: Allowing the team to deliver quality work increases job satisfaction. The users make the decisions regarding the quality.
- Teach Learning: Project members should learn to decide for themselves what they need to achieve their goals. For example, the developers are left to decide how many tests to write.
- Small Initial Investment: By focusing on the most important functions, initial usable systems are delivered quicker.
- Play to Win: The will to win is an attitude in XP. To play to win is far more motivating than simply wanting to avoid mistakes.
- Concrete Experiments: To minimize risks, decisions are underpinned by specific experiments.
- Open, Honest Communication: Attention is paid to open, honest communication. All project members are encouraged to enforce this.
- Work with people’s instincts, not against them: Trust in the team – even if an unusual approach is adopted to achieve a goal.
- Accepted Responsibility: Responsibility is not assigned, but should be taken. This creates very strong identification with the tasks.
- Local Adaptions: XP should be adapted to local needs and conditions because not all points from the textbook can be used in every project.
- Travel light: Do not provide too many tools and methods; the project should be supported by fewer, more effective tools.
- Honest Measurement: Some measurements are required to steer projects. These measurements must be taken honestly by the project members.
Practices of XP
The 4 values and 15 principles are supplemented by 12 practices. These practices are designed to help developers behave according to the principles.
- On-Site Customer: A central customer contact must always be accessible in order to clarify requirements and questions directly.
- Planning Game: Projects, in accordance with XP, run iteratively (repeatedly) and incrementally (gradually build on each other). The contents of the next step are planned before each iteration. All project members (incl. the customer) participate.
- Short Releases: New deliveries should be made at short intervals. Consequently, customers receive the required functions quicker and can therefore give feedback on the development quicker.
- Metaphor: Only a few clear metaphors should describe the system being developed so that the nitty-gritty of the system is clear to all of the project members.
- Collective Ownership: The whole team is responsible for the system, not individuals. Each developer must have access to all lines of code so that each developer is able to take over the task of another developer.
- Continuous Integration: All changes to the system are integrated promptly so that not too many dependencies between changes occur.
- Coding Standards: Regarding the common responsibility for the code, there should be a given common standard for writing the code.
- Sustainable Pace: XP builds on the creativity of the individual project members. This creativity cannot be achieved if the project team constantly works overtime. Overtime is to be avoided.
- Testing: All developments must be tested.
- Simple Design: The system should be designed as simply as possible so that it is easier to understand, modify and test.
- Refactoring: As soon as it becomes necessary to alter the structure of the system, it should be implemented.
- Pair Programming: There are always two developers sitting in front of a computer in order to increase the quality and transfer the knowledge better.
Dealing with Requirements
Requirements in XP are captured in the form of user stories on story cards. The customer formulates their requirements on an index card in the form of a story. Diagram 6 shows an example of a story card.
Diagram 6: Story card as an index card
This story is roughly assessed by the team and acceptance criteria provided by the customer. When and which user story is implemented is determined in the planning meeting to take place prior to iteration.
The story must be formulated so that it does not describe a technique, but be so comprehensively formulated that risks can be analyzed and efforts captured.
The details of these user stories are only discussed with the customer by the developer during the project. Once the story is implemented, the card is not kept, but destroyed. The documentation of the requirements then becomes the tests written by the project team.
Conclusion on the use of XP
The use of Extreme Programming is an advantage if the requirements available at the start of a project are not complete – this is very often the case. Requirements can change with XP during the project and can also be specified. Likewise, errors which were caused by the development team due to misunderstanding the requirements can be corrected in a simple way. With XP, it is considered that the parts of a project which promise the greatest benefit must be implemented first. As a consequence, the customer receives the most important functions very fast.
XP is self-organized to a large extent . This requires a certain minimum experience on the part of the team members. XP also relies on the courage of the team members, especially in the area of communication. If this is not possible with the team members, the use of XP is not necessarily beneficial.