Extreme Programming (XP) is an agile software development framework that aims to produce a higher quality of life for the development team and higher quality software. Among agile frameworks, XP is designed specifically for the most appropriate engineering practices for software development. It is based on five values: simplicity, communication, feedback, courage, and respect. Additionally, XP brings the whole team together to apply simple practices with enough feedback. This enables the team to see their status and tune accordingly for their unique situation.
When to use extreme programming
Extreme programming is the most suitable in the following scenarios:
– If the software requirements change frequently
– When the system functionality changes within a few months
– If the customer requirement is not clear
– When mitigating project risk is urgent especially in case of tight deadlines
– When the number of programmers is limited
– When automated unit and functional test cases can be created
– Fixed time project with new technology
– If continuous development and collaboration are priorities for the team
How does XP help in the above scenarios? – Since XP is a highly adaptable model, this encourages ongoing feedback from customers, enables developers to work together, and at the same time anticipates the errors along the way. As a result, XP produces better product releases with improved productivity.
Related post – Pair Programming: Does It Really Work?
Five Values of Extreme Programming
We have mentioned about five values of extreme programming. Here they are explained in detail –
Communication
Software development is a team activity that relies on communication. Effective communication between the team members helps to transfer knowledge among them. XP particularly stresses the importance of proper communication, including face-to-face discussion with the aid of different drawing mechanisms, including whiteboard discussion.
Simplicity
XP emphasizes simplicity in the whole process. To explain further, in extreme programming, the design addresses only the requirements and doesn’t predict the future. This is for keeping the system simple to be easily maintained, revised, and to provide support. Besides, it helps to avoid waste.
Feedback
Constant feedback helps to identify areas for improvement. With the review of previous efforts, teams can revise their practices. This also helps to maintain a simple design.
Courage
As per Kent Beck, XP’s courage is defined as “effective action in the face of fear.” Organizational issues must be addressed to increase the team’s effectiveness. Something which is not effective for work must be stopped. At the same time, an alternative must be tried out. Even though it is difficult to accept, you must have the courage to accept and act on feedback.
Respect
To streamline effective communication and feedback among the team members, mutual respect among the team members is essential. This helps the team members to work together to identify simple designs and solutions.
Extreme programming Practices
The core of Extreme programming is the set of software development practices listed below, which are interconnected to each other. You can do the practices in isolation; otherwise, some can be practiced in conjunction to mitigate the software development risk.
Twelve practices are used in XP as listed below:
- The Planning Game
- Small Releases
- Metaphor
- Simple Design
- Testing
- Refactoring
- Pair Programming
- Collective Ownership
- Continuous Integration
- 40-hour week
- On-site Customer
- Coding Standard
Here are the practices explained below–
The planning game
The XP planning approach is quite straightforward and realistic. It addresses two key areas of software development predictions –
- What will be done by the due date?
- To determine what to do next
It is not about analyzing what is required or how long it will take, as answering this is quite unrealistic. Instead, XP focuses on two planning steps to address the above two questions:
Release planning – In this practice, the customers present the programmers’ desired requirements, whereas the programmers estimate the difficulties of achieving the desired features. Afterward, they perform cost estimation and based on the features’ weightage, and the customer lays out a project plan. Based on the project plan, the initial release plan is prepared in which neither the estimation nor the priorities are solid. Once the team starts working, the XP teams regularly revise this release plan even though it is accurate.
Iteration planning happens every couple of weeks whereby the XP teams typically take two weeks to build the software, which is called iteration. Once they complete the build in each iteration, they deliver the software at the end of each iteration. Hence, during iteration planning, the customer presents the desired features or deliverables for the next two weeks. The developers break down the requirements into tasks, and cost estimation is done based on that. Based on the work done in the previous iteration, the XP team agrees or signs up for the task to be accomplished in the present iteration.
Apparently, the above planning is straightforward; however, they are immensely informative and controllable from the customer perspective. Moreover, the visibility on the progress is very transparent, and there is no concept of “ninety percent done” in the extreme programming model.
Small Releases
There are two important aspects of practicing small releases in XP. The XP team delivers fully tested and running software based on the customer’s feature choice in every iteration. The software is visible and workable to the customer at the end of each iteration, which can be used for either evaluation or release to the end-user. This keeps the entire process open.
The release cycle in XP is frequent. Creating good versions of software often seems impossible, but the XP team is doing it all time.
Metaphor
Metaphor in extreme programming is nothing but developing a common vision of how the program works. XP team uses a common system of names for understanding purposes. This helps everyone to understand how the system works and the right place for targeting functionalities.
Simple Design
In extreme programming, always an adequate design is used simply. Though it starts with simple continuous design, improvement, and testing is performed in the whole process. Furthermore, the design suits the current functionality accurately to minimize waste. It is neither a one-time job nor an up-front thing. Instead, it is an all-time thing.
Design steps are an inclusive part of the planning game. Additionally, the team engages itself in quick design sessions and revisions using refactoring. Since XP is an incremental and iterative process; hence, good design is essential. This is the reason design is stressed throughout the entire development.
Testing
Development in extreme programming is test-driven because it focuses on feedback, which essentially depends on software testing. Since the team works in very short cycles; hence, they can provide 100% test coverage. No doubt, extreme programming is “extreme” in this case. So, every time a programmer releases code to the repository, it is unit tested thoroughly. This works immensely helpful for design improvement, as well.
Refactoring
As we have mentioned that extreme programming focuses on an optimum design, which is essential to deliver business value in every iteration. Hence, continuous design improvement is a part of the XP process, which is known as Refactoring. The refactoring process focuses on the following improvement factors of design:
- Removes duplication
- Increases cohesion of the code
- Lowers coupling
Not to mention, high cohesion and low coupling is a sign of well-designed code. Refactoring helps to maintain simplicity in design, which helps to sustain the development speed in extreme programming.
Pair Programming
In software development, working solo might not always turn as the best solution. This has especially become a fact in the case of a bigger project. Pair programming, which is an agile development technique, produces good results and strengthens the team spirit. In this programming model, two programmers work on the same piece of code at the same time. I have explained Pair programming in my previous blog – Pair Programming: Does It Really Work?
Interestingly, XP strongly follows the pair programming model. This ensures another programmer than the coder at least once reviews the production code. This effectively ensures a better design, testing, and coding standard.
Collective Ownership
Collective ownership is the applied result of pair programming as the code gets benefits from many people’s contributions. This ensures the required features are placed in place. At the same time, combined attention improves the code quality. However, collective ownership could be a problem if the programmers involved in it don’t understand the code. However, XP eliminates this possibility by rigorous unit testing and pair programming. This also spreads knowledge throughout the team.
Continuous Integration
Extreme programming keeps the system fully integrated at all times. Daily builds are part of XP, and the XP teams do it multiple times a day. This significantly eliminates the chance of integration failure, often the fate of projects that build weekly or less frequently.
40-hour week
Extreme programming encourages that programmers should not work more than 40 hours a week. In case there is overtime in a week, the next week must not include extra overtime. Since XP follows short development cycles and continuous integration, it can avoid crunch time, which is a usual scenario in most projects. Since programmers get better rest, their productivity increases significantly. This sustainable development pattern also reduces production issues.
On-site Customer
In extreme programming, with each desired feature, the customer asks for one or more automated acceptance tests to establish the deliverable’s credibility. Automated tests prove effective when there is a pressure of a short release cycle where manual testing takes a considerable amount of time. The XP team builds the tests as per requirements to ensure the feature is implemented correctly.
Coding Standard
XP follows a common coding standard. It results in uniformity in all the code in the system and seems like a single individual writes it. This helps to maintain familiarity in the code.
Roles in Extreme Programming
Extreme programming does not establish specific roles like traditional projects. There is no specific guidance or description of how roles will be played in extreme programming projects. However, the four most common roles that are associated with extreme programming are as follows:
The Customer – Who makes all the business decisions related to business requirements, acceptance criteria, cost and budget, and deliverable order. It is assumed that a single person will play this role. However, that is quite absurd in real life as a single person cannot provide all the business decisions adequately.
The Developer – Everyone in an XP team is labeled as a developer. In extreme programming projects, a cross-functional team is expected as it can provide a mix of skills.
The Tracker – This role is often played by one of the developers who keeps track of the progress using relevant metrics. Some of these metrics are velocity, velocity changes, and the reasons for change, overtime amount, passed, and failed test cases. However, this role is optional and is implemented if there is a true need for it.
The Coach – If a team is new to extreme programming, it is often helpful to include a coach who has typically prior experience with XP. The coach can mentor the team as well as help them to maintain self-discipline. This helps to prevent mistakes in the process.
Final verdict
XP is a highly disciplined engineering practice that produces an effective and higher quality code in software development. It is often found that teams adopt agile methodology with a different framework and later shifted to extreme programming to a better result.
Additionally, XP focuses on practice excellence. So, it encourages teams to perform the practices extremely well. The teams continuously improve to perform the practices better way.