Piotr Rzeźnik | Project management | 13.04.2022
During software development projects, we often face challenges such as changing customer requirements. Agile teams can take effective actions to change any part of the system to respond to the feedback received. Extreme Programming (XP) methodology provides such opportunities. How is it different from frameworks like Scrum? What projects will it work in and what are the pros and cons of the Extreme Programming approach? Which software engineering practices in XP are the key to success? Let’s find out!
Extreme Programming is an Agile software development methodology. XP is based on values, principles and practices. Its main goal is to enable small and medium-sized Agile teams to deliver high-quality software, while adapting to changing customer requirements.
What distinguishes Extreme Programming from other agile approaches is the way it places emphasis on the technical aspects of software development. XP precisely defines the way developers work, which results in delivering high-quality software within the requisite period of time.
Simply put, Extreme Programming puts… extremely strong emphasis on good coding standards.
Extreme Programming dates back to the 1990s and was created by Kent Beck, also known as one of the 17 developers who signed the Agile Manifesto. It all started during a project which Kent Beck was involved in. In 3 years of project development, no major progress had been made, so Beck, who was new to team management, decided that teaching the team the techniques and practices that worked for him would be the best idea. Practices such as programming in pairs and TDD (Test-Driven Development) were successfully implemented. Based on this experience, in 1999 Kent Beck collated the practices, values and principles of Extreme Programming in his book “Extreme Programming Explained: Embrace Change”.
How is XP different from traditional approaches? Extreme Programming is an Agile methodology, in which it is important to make changes smoothly. Instead of sticking to a specific, top-down plan, agile teams act flexibly.
Extreme Programming is very different from traditional methodologies, such as Waterfall.
|Waterfall approach||Extreme programming|
|Planning phase||Iteration Planning at the beginning of each iteration (usually it takes only one week)|
|Programming phase||XP teams test software early – according to the Test First programming approach|
|Testing phase||The code is written using Pair Programming techniques|
|Implementation||Work on small pieces of functionality and integrating them with other functionalities|
One might ask: all right, but doesn’t Scrum (which also focuses on incremental development) also offer all the above-mentioned possibilities?
Scrum is a framework that helps teams develop complex projects in an iterative way and does not impose strict rules as to how developers do their work. The main difference is that Extreme Programming, as previously mentioned, places strong emphasis on good coding practices.
In addition, it is directly related to programming, and Scrum can be applied to any project in which an iterative approach will work.
Extreme Programming is open to changes in its components (meetings, artifacts). Teams can and should adapt artifacts to their needs. On the other hand, the Scrum Guide states that “while implementing only parts of Scrum is possible, the result is not Scrum”. Scrum is a framework that needs to be complemented with one’s own processes and methodologies. This means that it is not only possible to use Extreme Programming and Scrum at the same time, but it even comes highly recommended.
Test as early as possible. What is shift-left testing?Read the article
Extreme Programming is based on values, practices and principles.
Values set a goal for a team. They work like a GPS that guides decisions at a high, abstract level. Due to the abstract nature of values and their genericity, it is difficult to obtain specific guidelines. For example, the claim that “communication is appreciated” can be understood vaguely (e.g. as dedicating Daily meetings to discussing only topics not related to the needs of the team and the client).
They are, in a sense, the opposite of values. Values are general and theoretical concepts, while practices are the specific processes defining what needs to be done. Practices, therefore, help teams to keep values in mind. Example: Value – Communication. Practice – Knowledge transfer in a team.
These are domain-specific guidelines that bridge the gap between practices and values.
Extreme Programming values are: simplicity, communication, feedback, commitment and respect.
This can be described by the following sentence: “Do the simplest things that work”. However, this is often misunderstood, which leads to doing the simplest things such as changing style etc., and not those changes that provide real business value.
Keep in mind that simplicity in software development is a highly relative concept. Often what is simple for one team will be difficult for another. It all depends on skills, knowledge and experience.
Lack of communication prevents the flow of knowledge inside the team. Often, when a problem arises, one of the developers may already know how to solve it. However, the lack of communication prevents other people from knowing the problem or getting closer to solving it. It may turn out that several people try to tackle it simultaneously and independently, and this slows down the whole team.
When using Extreme Programming, teams try to get feedback as early as possible and on a continuous basis. If there is a need for change, we, as programmers, want to know about it as soon as possible.
Feedback takes many forms and can vary in scope. When programming in pairs, comments from the other developer are direct feedback, as are the opinions of other team members – including the client, who is also a member of the team.
Tests are another source of valuable feedback. If writing tests is difficult and causes a lot of issues, it means that the architecture or solutions used in the project are too complicated and need to be simplified. It may turn out that a team receives more feedback than they can handle. Then there is a risk that in a number of cases, more important feedback will be omitted. You should then analyze why there is so much feedback and what needs to be changed.
Kent Beck defines courage as “effective action in the face of fear”. A software engineer has many reasons to be anxious, and at the same time many opportunities to demonstrate commitment.
Telling the truth, especially if it is unpleasant, for example about unrealistic estimates, requires courage. This is also the case when it comes to giving and receiving feedback.
The basic principle of Extreme Programming is that everyone cares about the quality of the code and engages in their work. Even the most state-of-the-art technological stack won’t save the project if there is no respect and care within.
The rules in Extreme Programming provide more detailed guidance than values. Principles explain values and make them clearer, eliminating unambiguity. For example, based on the value of courage, we could conclude that making a big change in the code is recommended. However, according to the principle of small steps, large changes are risky, so the changes introduced should be as small as possible.
Software is created by people for people. This is an obvious but often overlooked fact. However, taking the strengths, weaknesses and needs of a person into account is important, as it allows you to create products that people want to use. A work environment that gives opportunities for accomplishments and development, a sense of belonging, and space for work-life balance fostering a sustainable pace of work, is also a place where it is easier to take the needs of others into account.
XP teams are guided by economic factors when creating software, constantly assessing the risk and needs of the project. For example, User Stories shall be implemented first in terms of business value, and not in terms of technical issues.
In an XP project, you avoid solutions in which one side benefits at the other’s expense. For example, extensive documentation and specification can help someone to understand the issue, while pulling the team away from implementation and delaying it.
A mutually beneficial solution is, for example, the use of automated acceptance tests. You get instant feedback on implementation, developers get precise code specifications, and users get faster access to functionality.
In accordance with the principle of improvement, teams do not strive for perfection in the initial implementation phase, but for implementation that is good enough. They then continuously learn and improve the product thanks to feedback from users.
XP practitioners create code in small batches using TDD (Test-Driven Development). They combine their code with the code from the main branch several times a day, not just every few weeks or even every few months. The development of the project itself takes place in short iterations, not in long-term phases.
According to Kent Beck, an experienced, or mature, XP team should not rely on rigidly defined roles. Keep in mind that roles can be helpful for inexperienced teams. Over time, however, they may hinder effective cooperation.
Roles and responsibilities in the context of Extreme Programming:
It would be best if there were a real customer / Product Owner on site to answer questions, prioritize user stories or collaborate on acceptance tests.
In XP teams, developers perform task delivery and history estimations, write tests and deal with implementation.
It is not necessary to have a person in this role when using the XP approach. Such a role can be taken by a person who already has experience in Extreme Programming. The trainer’s task is to make sure that the team uses good practices, turning them into habits and not going back to the old ways of creating software.
This is a person who tracks the progress of the team and talks to each developer. Consultations with each team member allow that person to identify blockers, bottlenecks and find ways to solve them. It is also the duty of the Tracker to present metrics showing how the team handles its velocity, and burndown charts. Often, in order to show such metrics, ready-made solutions, such as Scrum or Kanban boards, are used to automatically calculate statistics.
Extreme Programming includes 5 processes that are repeated iteratively:
Extreme Programming can be used in any software development project, but the positive and negative aspects of this approach and the differences between other agile frameworks should be considered.
Using XP can be beneficial and it helps to reduce the time and cost of software development:
On the other hand, Extreme Programming has a number of disadvantages that you need to take into account when choosing this approach for your project:
Extreme Programming will work in teams where:
Extreme Programming will work well in software projects where customer requirements often change. This may involve more meetings, the need to engage the customer to get feedback, and to make changes to the team structure. However, if cooperation and continuous development are a priority for your team, it’s worth giving Extreme Programming a try. This highly flexible approach is based on continuous feedback from customers, anticipates errors that may occur along the way, and includes the cooperation of developers due to programming in pairs. Extreme Programming not only ensures the delivery of a product that brings business value, but also increases the productivity of the development team.