Intro to XP
Table of Contents
Understanding XP – its values and principles
Comparison with other agile methods
What is XP?
XP, short for Extreme Programming, is part of a bigger group of agile methodologies. Agile methodologies are project management approaches that divide the project into phases, with a focus on collaboration and ongoing improvement. XP is one of the most specific frameworks since it imposes engineering practices. It also specifically stresses customer satisfaction, which we will see being reflected in its values and principles as we discuss them later.
Is XP for me and my team?
Before we dive further, you should check if XP makes sense for your team!
Implementing XP for your team would be useful if:
- requirements for the project are constantly changing
- collaboration is important to your team
- pair programming makes sense for your team
- customer wants to be constantly involved in decision making (almost on a weekly basis)
- your team size is small to medium (ideally between 2 to 12 developers)
Understanding XP – its values and principles
XP is made up of two core parts: its values and its principles.
Think of values as high-level ideas that help guide the team through decision making. Principles on the other hand are more low-level, giving speciifc instruction to address common issues.
As we look into them, we will explain how such practices will ultimately lead to better customer satisfaction.
Values
1. Communication
- Teams should aim for open and effective communication — not only between team members, but also between stakeholders.
- Teammates should actively communicate problems that they are facing, so that if others have already worked through a similar problem, there is no need to reinvent the wheel.
- Timely and honest communication about development progress to stakeholders will allow changes to be made earlier, preventing major overhauls in the future.
2. Simplicity
- Developers should always go for the simplest working solution to the problem. This avoids unnecessary complexity, leading to a faster development time when teammates are working together.
3. Feedback
- Continuous feedback loops will involve customers throughout the development process, ensuring that their input is considered. This iterative approach also allows for adjustments based on customer preferences and needs too, leading to a product that better meets expectations.
4. Courage
- Courage is required when making necessary changes, particularly the challenging ones. This adaptability though ensures timely response to customer’s changing requirements, ultimately giving them a product that closely aligns with their expectations
5. Respect
- This involves valuing customer input, even if they are not as technically compotent. This also involves respect amongst developers, for each other’s work and also for the product itself. This respectful environment fosters better work.
Principles
There are a lot of principles when it comes to XP, but here we have summarized ones that would affect developers the most.
1. Pair programming
- Two developers should work together at one computer, promoting collaboration, knowledge sharing and hence producing higher quality code.
2. Whole team
- Not only team members should be in the development process, but also customers and business stakeholders. This spreads the responsibility of the project’s success between everyone, and also helps keep the project keep on track during changes.
3. Continuous integration
- Change should be embraced throughout the project, even if not originally decided upon.
4. Test-first programming
- Instead of the typical process of first writing code then writing tests, the path changes to writing tests, then writing code to pass those test. This reduces the amount of bugs.
5. Short development cycles
- Sprints should be done in 1-2 week durations.
6. 10-minute build
- Building the whole system should be done automatically, and all tests should be able to run within 10 minutes. The 10 minute limit is because any longer build times would disencourage frequent builds, which inevitably introduces more errors over time.
Comparison with other agile methodologies
XP vs Scrum
1. Duration of sprints. Scrum teams usually work on sprints that are 2 weeks to 1 month long. XP sprints are usually only 1 to 2 weeks long.
2. Flexibility during sprints. For Scrum teams, once the sprint planning has been done, the expectation is to deliver those items by the end of the deadline. However, in XP, due to the higher emphasis on responsiveness, as long as the team hasn’t already started work on a feature, another feature of similar workload can be swapped in.
3. XP prescribes engineering practices. As we have discussed, XP has a lot of specific implementation details that developers need to follow.
XP vs Waterfall
1. Plan as you go. Instead of a separate planning phase, planning takes place at the beginning of each sprint, which only lasts 1-2 weeks each.
2. XP tests before, Waterfall tests after. In XP, tests are written before code is even implemented.
3. Smaller chunk-based contributions. Instead of working on big features alone for a long period of time, developers work on small chunks and push as they go. This avoids massive merge conflicts in the future, saving time.
Further reading
If you would like to learn more about the other principles of XP, here is a good article on it.
https://www.nimblework.com/agile/extreme-programming-xp/#:~:text=Extreme%20programming%20is%20a%20software,to%20evolving%20and%20changing%20requirements.
References
https://www.nimblework.com/agile/extreme-programming-xp/#:~:text=Extreme%20programming%20is%20a%20software,to%20evolving%20and%20changing%20requirements.
https://www.agilealliance.org/glossary/xp/
https://kanbanzone.com/resources/agile/extreme-programming-xp/
https://www.mountaingoatsoftware.com/blog/differences-between-scrum-and-extreme-programming
http://www.extremeprogramming.org/