The advent of Extreme Programming (XP) dates back to the mid '90s when Chrysler Comprehensive Compensation (C3) program was initiated and Kent Beck was brought on to the project to improve the performance of the system.
This is extremely helpful where customer requirements keep on changing and the team has to adapt to short development cycles. Each user story is associated with acceptance tests and for a story to be considered done, the acceptance tests have to be passed (which can be automated). XP proposes the tests first and the code second; therefore it is required for the test cases to be ready before the coding starts. Before integration, it is required that all the test cases are ready.
The development cycle starts with the customer setting a set of requirements/stories. This will decide the outcome of a development cycle. Simultaneously, the team starts estimating the stories. Here, the size of the story along with its benefit is estimated so the business can make a decision regarding the priority.
There is also a concept of ‘Spike’ or time boxing. In cases where the team is not able to estimate a particular task owing to its technicality, that particular task can be time-boxed and some decided amount of time can be assigned to it.
The team can research and come up with a better estimate. The spike can be introduced before, during, or after a development cycle. Now, the team comes up with a release plan which is the most desirable by the team members. These stories are a first estimate of what the team will deliver in a release (A release cycle can have several development cycles).
Then, the team starts with its series of weekly cycles. At the end of each development cycle, the team gets together with the customer to finalize which stories should be addressed next. Now, just like scrum, the team breaks up these stories into smaller tasks and estimates them according to the timeline of one week.
At the end of the week, the team and the customer review the progress and based on this, the customer can make the decisions regarding the progress of the project.
![]()
Image source: Wikipedia
The five pillars of Extreme Programming,
- Simplicity
Keep it in the simplest form possible. This ensures that rework and waste of effort are avoided. Work only on what you know.
- Communication
Each of the team members should communicate to the others daily. It is also suggested that the team should not be separated by cubicle walls so that the communication while the work is going on is easier.
- Feedback
Feedback plays an important part. Feedback on previous efforts can help the team to work better in future.
- Courage
Be transparent in telling the team about their feedback, Be courageous enough to accept feedback on you and raise your voice against any organizational policy that is affecting the team’s productivity
- Respect
Respect the contribution of all the team members.
The Roles involved - Customer
The one for whom the software is being developed.
- Developer
The one who is developing it. Apart from developing he also participates in estimation of stories.
- Tracker
The one to keep the team on track if everything is working as planned, if there are any roadblocks etc,
- Coach
Teaches the team about the agile principles and contributes to making the team more agile.
- Doomsayer
Flags potential problems and helps keep trouble in the correct perspective.
- Manager
Schedules the meetings ensures everything is on time.Th manager does not decide anything for the user stories this is done by the customer.
- Gold owner
The one to fund the project. Could or could not be the customer.
Multiple roles can be played by the same person. There were 12 practices proposed by XP initially
The Planning Game,
- Small Releases
- Metaphor
- Simple Design
- Testing
- Refactoring
- Pair Programming
- Collective Ownership
- Continuous Integration
- 40-hour week
- On-site Customer
- Coding Standard
However, they have changed now and the new practices as described in the second edition are listed below.
- Sit Together
- Whole Team
- Informative Workspace
- Energized Work
- Pair Programming
- Stories
- Weekly Cycle
- Quarterly Cycle
- Slack
- Ten-Minute Build
- Continuous Integration
- Test-First Programming
- Incremental Design
Some of the drawbacks of Extreme Programming are,
- Extreme Programming is found to be more effective in only smaller groups.
- Pair programming does not work well in many cases.
- There is a huge dependency on the customer.
- It is very difficult to add to the current project as it has simplicity as one of the values and it might not be possible.