What is Extreme Programming?

Extreme Programming – often abbreviated simply to XP – was developed in the mid-1990s by Kent Beck, Ward Cunningham and Ron Jeffries while working on a project at Chrysler Comprehensive Compensation System to develop a payroll system for Chrysler Corporation. As a team, they faced a number of challenges, including tight deadlines, changing requirements and a lack of clear direction. They began experimenting with different approaches, eventually developing a set of principles and practices that quickly gained popularity among software developers and were used in many organisations from then on.

After describing the concept in a series of articles, Beck presented XP to a wider audience at the Object-Oriented Programming, Systems, Languages & Applications (OOPSLA) conference in 1996 and published the book “Extreme Programming Explained: Embrace Change” in 1999.² The book provides an overview of the methodology and its underlying principles, as well as practical guidance for implementing XP in software development projects.

Different perspectives on Extreme Programming

When developing software, different interests and perspectives of the people or groups of people involved collide. In order for the cooperation to work, these interests and perspectives must be explicitly taken into account. Or formulated differently: The individual benefit of the people (groups) involved is an essential success factor for the success of the project.

The following groups of people or perspectives can be distinguished:

Customer perspective: Extreme Programming assumes that a customer does not know all the requirements at the beginning of the project and is not able to structure or prioritise them correctly. It is therefore normal that the customer identifies new requirements in the course of a development, changes his mind about existing wishes or prioritises individual aspects differently. It is therefore important for the customer to have a procedure in which he can exert a controlling influence on the development.

In XP, short development cycles, regular exchange and feedback ensure that the customer actually receives software that meets his requirements and expectations. However, this flexibility comes at a price: on the one hand, the customer commits to actively working with a defined development team throughout the entire development process; on the other hand, he also recognises that a formal approach with a comprehensive customer specification or SRS specification makes little sense. In a way, constant exchange, trust and open communication are an important basis for cooperation between the stakeholders.

Developer perspective: Short development cycles are also beneficial for developers, as they receive feedback from other stakeholders – customers, customer representatives, users, key users or internal managers – after only a short time. Thus, their risk of developing the wrong things or developing things incorrectly decreases.

Short development cycles offer additional advantages:

• Effort estimates, ideally done in a team, become more accurate as the amount of requirements to be realised within an iteration decreases.
• The implementation of tests becomes relatively easier and the elimination of possible errors presumably less costly.
• And the team gets the opportunity to see itself as a team. Together it is important to achieve benefits for the customer, together it is important to make the next iteration successful, together it is important to produce quality.

However, developers must also accept that the programme code belongs to the entire team, regardless of the creator, and that internal feedback is expected and ideally also desired from everyone.

Project and organisational perspective: The continuous analysis and improvement of Extreme Programming is a central element of the method. In this way, XP borrows from the Japanese philosophy of Kaizen. The term is composed of the two Japanese words Kai (change) and Zen (for the better), whereby the endeavour is not to focus on perfection from the beginning, but to address permanent improvement. This perspective concerns both the people involved in development and the organisation as a whole, and is reflected in the values, principles and practices of the method.

The values in Extreme Programming

Kent Beck defines five values on which Extreme Programming is based:

• simplicity,
• communication,
• feedback,
• courage and
• respect.

Simplicity means that the simplest solution that meets the requirements should be realised. Simplicity thus becomes the answer to complexity, minimising it and, for example, reducing the documentation effort.

Clear and continuous communication between those involved is indispensable for the success of the development. This is the basis for using the existing knowledge of those involved in the project. Often, problems can be solved through communication because one of the participants already knows the solution.

Regular feedback from customers not only increases the quality of the software, but also promotes satisfaction in the team. At the same time, feedback reduces the probability of undesirable developments and consequently lowers the effort required to eliminate them.

Courage is the basis for the first three values: simplicity, communication and feedback. Without courage there is no exchange, critical issues may not be addressed, mistakes may be concealed or unrealistic wishes may not be discussed.

Respect describes the attitude between the participants, between clients and developers and between the developers themselves. Both opinions and achievements are respected. (This may sound easier in theory than it sometimes is in practice).

Principles in Extreme Programming

In addition to values, XP also defines 14 principles:

• Humanity
• Economics
• Mutual Benefit
• Self-Similarity
• Improvement
• Diversity
• Reflection
• Flow
• Opportunity
• Redundancy
• Failure
• Quality
• Baby Steps
• Accepted Responsibility

Software is developed by people. Humanity means that, for example, an appropriate work-life balance not only boosts morale and motivation, but also improves the efficiency of everyone involved. In addition, humanity is an important factor for teamwork, the acceptance of responsibility by those involved and mutual feedback.

Economics addresses the intention to develop software profitably. Despite all humanity, it is also about making profits. Of course, the developed software must meet the defined requirements of the client, but at the same time it should keep costs and resources as low as possible. Here, it is important to find the right balance between features, costs and customer satisfaction to ensure that the development makes economic sense.

The principle of mutual benefit in Extreme Programming (XP) states that both the development team and the client should benefit from the collaboration. It is about both parties clearly communicating and aligning their needs and expectations to achieve a common goal: developing high quality software that meets the client’s requirements. This requires close collaboration and open communication to ensure that the project is successful and that both the team and the client are satisfied with the outcome.

Self-similarity addresses reuse as a principle. It is about not always reinventing the wheel, but reusing approaches, structures, ideas from solutions that have already been developed. However, it is not about copying an existing solution, but using it as a reference point when needed.

Do you remember Kaizen and the project or organisational perspective? Software cannot be developed perfectly from scratch – changing requirements, new wishes or ideas, errors, side effects prevent this. In addition, technology often evolves – what seemed almost impossible yesterday works without much effort today. Improvements increase both the quality of the product and the satisfaction of the customer; the prerequisite is that the values of communication and feedback in particular are lived.

Diversity is a principle that requires the team to be composed of members with different backgrounds, skills and experiences. Diversity enables teams to look at problems from different angles and find solutions. It is about using the strengths of each member and encouraging team members to work together to make the development of the software permanently better and more successful.

Reflection is about enabling the team to evaluate itself and improve the way it works together. Sharing experiences, identifying problems, changing approaches and supporting each other actively contribute to improving the quality of the software, increasing productivity and improving the satisfaction of team members and the customer.

A fundamental idea of XP is the flow principle. It is about maintaining a steady flow of work throughout the development process. It is about ensuring that the work always gets done and that the team makes steady progress towards completing the project. This can be achieved by, for example, dividing the project into short iterations in which small work steps – for example, in the form of so-called user stories – are realised. Ideally, the project progresses smoothly in this way. Furthermore, this principle also refers to the idea of minimising interruptions and distractions in order to maintain the team’s concentration and productivity.

Problems in the course of software development are not uncommon. Problems are opportunities. It is important to see problems as opportunities for improvement and as an aspect of a learning process. Incidentally, feedback and communication are similar – these values can also be used as opportunities.

The principle of redundancy is applied in the development process by having several people working on the same task or function, or by having several ways to solve a problem. This redundancy helps to ensure that the project can continue even if something goes wrong or an unexpected problem arises. It also helps to mitigate risks and improve the quality and robustness of the final product.

The principle of failure is based on the idea that it is better to fail early and often than to wait until a late point in the development process. This principle encourages the team to recognise potential problems early and take steps to mitigate them, rather than waiting unnecessarily and incurring costly delays and rework later in the development process. In addition, this principle also refers to the idea of accepting and learning from failures, which allows the team to continuously improve and adapt to changing requirements or unexpected problems.

Developing high-quality software in a flexible way is a claim of Extreme Programming. In practice, however, the desire for economic efficiency and the pressure to cut costs can compromise the quality of a piece of software. To prevent this, XP does not address costs as a benchmark. In addition, no end dates are fixed, as this could also influence quality. Without time flexibility, possible improvements fall by the wayside and customer wishes remain unfulfilled.

Baby steps is a central principle in XP. Small steps create a continuous flow, so changes can be made promptly, so feedback on features can be implemented. At the same time, the principle helps to minimise risks of undesirable developments and the probability of failure.

Accepted responsibility is the last of the 14 principles. It states, for example, that a developer who is responsible for editing a user story takes responsibility for the implementation and thus for the design, coding and testing.

Practices in Extreme Programming

XP defines main and concomitant practices or primary and secondary practices:³

The following 13 main or primary practices are mentioned:⁴

• Sit Together
• Whole Team
• Informative Workspace
• Energetic Work
• Pair Programming
• Stories
• Weekly Cycle
• Quarterly Cycle
• Slack
• 10-Minute Build
• Continuous Integration
• Test-First Programming
• Incremental Design

XP postulates, on the one hand, that spatial proximity promotes communication between participants and, on the other hand, that there must be sufficient space for individual privacy. The workplace should be “informative” in the sense that all important information is clearly visible from every workstation.⁵ In general, the team is more important than the individual. It makes joint decisions, exchanges ideas on a daily basis and solves problems independently. Ideally, work is done in a collegial atmosphere, with full motivation and without overtime. Safety buffers are calculated in and unfulfillable promises are avoided. The goal is maximum productivity.

The functionality to be developed is described in the form of user stories.⁶ Customer requests are realised in weekly cycles, the project with its releases is planned quarterly. The quarterly cycles are also suitable for an exchange with all participants to discuss what has been achieved so far, challenges and next steps.⁷

The software is developed using test-first programming – a corresponding test is written before a functionality is realised – and changing partners in pair programming. The build of the software should not take longer than ten minutes and all code changes made by the developers should be saved in a central repository approximately every two hours. At the same time, incremental design, which incorporates feedback and new insights, continuously improves the design of the software.

The following 11 accompanying practices or secondary practices are mentioned:

• Real Customer Involvement
• Incremental Deployment
• Team Continuity
• Shrinking Teams
• Root-Cause Analysis
• Shared Code
• Code and Tests
• Single Code Base
• Daily Deployment
• Negotiated Scope Contract
• Pay-Per-Use

The client plays a central role in the development process, regularly participating in meetings and actively contributing to the definition of the functional scope to be developed, which is the subject of negotiations. In order to jointly minimise possible risks and at the same time increase flexibility, the functional scope can be fixed in smaller agreements. Depending on the context, payment can vary; for example, instead of an agreed payment on release, a payment model such as pay-per-use could be used, in which active use of the software triggers payment.

In order for the development team to acquire the skills to work together effectively, it makes sense to keep it consistent over several projects. As the team becomes more competent and productive over time, its workload should remain constant, even if resources are shifted to other teams.

The code as a central medium plays a crucial role in the development process. It is stored in a repository so that only one common code base exists. Developers are encouraged to edit or use colleagues’ code as well, which promotes collective ownership of the code. Along with code, tests are a crucial part of development. Other forms of documentation are generated from code and tests alone.

Incremental deployment is used to recognise difficulties early on. When legacy systems are replaced with new software, one part at a time is replaced to make the entire process more predictable. Deployment is done incrementally and on a daily basis. This routine minimises costs and errors and enables both continuous integration and the use of acceptance tests. When errors occur, a root cause analysis is carried out with the aim of preventing the error from occurring again and enabling the team to avoid producing the same error again.

Advantages and disadvantages of Extreme Programming

Extreme Programming offers some advantages, especially compared to the waterfall model that was more common at the time of its release in the mid-90s:

• It actively integrates the customer into the development. They can make their wishes known in the ongoing project, formulate new requirements or reprioritise existing requirements. He gets to know the team of developers better, gains trust in the people involved and acts as a “real” contact person.
• Short development cycles, early error detection and regular feedback ensure a product that ideally meets the current wishes and requirements of the customer and thus provides real benefits.
• The values define a framework of cooperation and a common standard for the high-quality development of software.
• The principles help to make togetherness more tangible. In a way, reality enters into software development.
• The practices formulate aids and approaches that make work easier and make quality an inherent part.

These advantages are also countered by some disadvantages, especially when compared to current approaches:

• Test-First Programming and Pair Programming may have advantages in certain contexts, but generally preferring them to other approaches is not always purposeful.
• Working in organisations whose employees share values is often advantageous, but cannot really be forced or prescribed. Values are individual, so organisations do well to provide working conditions that encourage working in a common direction.
• It makes sense to pay attention to the well-being of developers, but perhaps this should actually refer to the working environment. Nowadays, it is not uncommon for software development to take place independently of location. Postulating joint development on site, for example, is therefore rather counterproductive.
• Implicitly, Extreme Programming assumes that there is a kind of ideal customer who, for example, does without comprehensive documentation, who does not need a specification and for whom fixed deadlines are less important. Implicitly, there is also an ideal programmer who renounces personal code ownership, is open to permanent changes and, of course, appreciates the advantages of test-first programming and pair programming. It is possible that the ideal client and the ideal developer will never meet in real life.
• In general, XP describes values, principles and practices, but it remains unclear what happens when teams decide to define their own values, follow other principles or omit practices.

By the way, opinions vary as to whether the name Extreme Programming is an advantage or a disadvantage. On the one hand, it sounds extreme in the truest sense of the word and emphasises the clear departure from previous approaches. On the other hand, it has been overtaken by the present, especially since many practices are common nowadays and, on closer inspection, there is little extreme in the approach.

Similarities and differences between Extreme Programming and Scrum

With Scrum, there is an approach that – also originally based in software development – propagates a likewise agile approach. What are the similarities and differences?

Similarities:

• Both approaches formulate values: simplicity, communication, feedback, courage and respect in XP, self-commitment, courage, openness, focus and respect in Scrum. Even if the values differ in detail, the naming of values is a common feature.
• Both approaches propagate short iterations and an iterative procedure with regular exchange and continuous feedback. In addition, they are based on empiricism (knowledge arises from experience and decisions are made jointly on the basis of observations) and lean thinking (waste is avoided and the focus is on the essentials).
• In general, the proximity to the Agile Manifesto is recognisable in both approaches; for example, both procedures value functioning software more important than extensive documentation.
• Scrum defines accountabilities, Extreme Programming names the accepted responsibility as a principle.
• Even though Scrum has said accountabilites with the Scrum Master, the Product Owner and the developers, and XP describes different perspectives such as the customer or the developer perspective, no approach defines further roles.
• Scrum explicitly defines events (Sprint, Sprint Planning, Daily Scrum, Sprint Review and Sprint Retrospective), XP labels formats for exchange less explicitly, but there too there is planning of short (weekly) cycles, daily exchange, review of work results as well as exchange on improving collaboration.

Differences:

• Both XP and Scrum have a close connection to the Agile Manifesto.7 However, while Extreme Programming formulates “own” principles, Scrum does without. Explicit practices are not formulated in Scrum either, but they can be found implicitly, for example in the form of defined commitments.
• Both approaches have their origins in software development, and XP is still at home there today. Scrum, on the other hand, is now defined as a framework for the development and maintenance of complex products and services, which has been used for many years in different areas and industries for product development and project management.
• A big difference can be recognised in the marketing and distribution: Scrum is described with the help of the Scrum Guide – in the English original compact with 14 pages. In 2020, the 7th version was already published. This has been translated into 80 languages. Regardless of whether this is cause or effect, it shows that Scrum enjoys great importance worldwide – and across industries. XP, on the other hand, has neither a corresponding reputation nor a comparable spread.

Impulse to discuss:

Is XP suitable for fixed-price projects, use in distributed environments or for projects with fixed completion dates?

Notes:

[1] In some publications, Extreme Programming is also described as a process model or a collection of best practices. Other publications classify the approach as implicit risk management, which addresses risks implicitly without using explicit procedures – e.g. in the form of documented risk lists.
[2] Extreme Programming Explained: Embrace Change, Second Edition
[3] In the first edition of Kent Beck’s book, 12 practices were mentioned: Planning Game, Small Releases, Metaphor, Simple Design, Testing, Refactoring, Pair Programming, Collective Ownership, Continuous Integration, 40-hour week, On-site Customer and Coding Standard. In the 2nd edition, there were then 13 primary and 11 secondary practices as described. The originally mentioned aspects are also described as traditional and the new versions as evolutionary practices. They concretise or modify the original explanations to make their use clearer and more comprehensible. In terms of content, the metaphor, which was difficult to implement, and the programming standards were dropped.
[4] Ron Jeffries formulated another XP skin practice with Customer Tests.
[5] Obviously, physical proximity was formulated as a practice before efficient, goal-oriented work in a home office seemed possible. The visualisation of information on walls in the course of an “informative workplace” also seems somewhat “one-sided” or partly “outdated” in view of today’s software solutions. Here you can find an article about the advantages of remote work.
[6] Again and again it is claimed on the internet that the User Story goes back to Scrum. This is wrong. It originated in XP as an element in the Planning Game. The Planning Game is considered a traditional practice.
[7] Not only the three inventors of XP (Beck, Cunningham and Jeffries) signed the Agile Manifesto, but also the two inventors of Scrum (Jeff Sutherland and Ken Schwaber) are among the 17 first signatories.

Here you will find additional information from our Smartpedia section:

t2informatik develops and modernises software as a service provider. Click here to learn more.