Why you should adopt Extreme Programming practices?
Extreme Programming (XP) practices might seem too extreme for junior developers and for those who are on the business side of an organisation. Encouraging merciless refactoring, comprehensive testing, collective code ownership and pair programming among other practices; it’s been often seen as an engineering-centric approach that brings more value to developers than to business.
- So why would you work in pairs on the same task?
- Do you really need to write a test before every code change?
- Should we spend time on refactoring instead of building more new features?
These are the questions that you might hear from managers in a feature-factory setting or even in more enlightened organizations.
While benefits gained from practicing XP might not be obvious for business decision makers, many development teams eventually are likely to mature and come to some of the XP practices naturally or with a help of a software craftsperson driving change from inside the team.
Some [developers] may even be lucky enough to find themselves doing Extreme Programming, also known as “The Scrum That Actually Works”.
Ron Jeffries, “Developers Should Abandon Agile”, May 10, 2018
Since XP is rarely used as the only agile methodology and with its adoption rate of 1% according to the Annual State of Agile Report; organisations tend to combine XP with prima ballerina of Agile frameworks – Scrum.
So what are the core XP practices and why you should adopt them?
Kent Beck developed XP while working on a payroll project at Crysler and described its core practices in his first book Extreme Programming Explained, published in 1999 almost two years prior to the Agile Manifesto creation. The practices he recommends adopting are:
1. Simple code and design
Simplicity is the means to flexibility and building software that’s easy to change. Beck suggests thinking about the question “What is the simplest thing that could possibly work?” to achieve simplicity and eliminate unnecessary cumbersome features that complicate the system.
2. Refactoring
Refactoring might seem like a fancy technical term but essentially it means redesigning existing code without changing its behaviour. Why do you need to redesign something that works? To find code’s optimal design and contribute to simplicity.
3. Coding standards
Code as any form of language has its specific conventions that help developers to communicate within the project. Well-defined coding guidelines facilitate communication through code and save time.
4. Common vocabulary
Common vocabulary and a memorable metaphor to describe a feature or a system help to clarify and explain complex technical concepts in ground-to-earth ideas. For example, describing your system as a Lego set and how different components are assembled and connected to make everything work together can be a resonant image.
5. Test-driven development
Test-driven development advocates creating a test before writing code per each unique component of the system. In doing so, it’s possible to identify problems at early stages, validate that the current code is enough to implement the required feature and feel safe to introduce changes.
6. Pair programming
Working in pairs helps to share knowledge and experience within the whole team, while positive peer pressure tends to promote coding standards and good programming habits. Programming in pairs also contributes to creating a sense of collective code ownership and teamwork.
7. Collective code ownership
When the entire codebase belongs to the whole team rather than when specific areas belong to specific individuals, there is a smaller chance of creating a “single point of failure”. Adopting collective code ownership along with pair programming prevents team members from developing an attachment to an individual subsystem or feature rather than to the entire product. After all, people do need holidays, take sick leave and occasionally leave companies.
8. Continual integration
Continual integration presupposes merging working code into the main repository as soon as it’s completed to keep an environment in an up-to-date, releasable state. Small, incremental changes reduce the impact that dramatic, large changes might have and help to keep everyone on the same page, working with the freshest version of an application.
9. Customer in the team
A real customer in the team or someone representing a customer’s voice (i.e. Product Owner in Scrum) provides a business perspective and addresses business concerns proactively with the team. The “customer” is responsible for the project’s scope, which is a set of features the team would deliver. They write story cards that describe required features in a sentence or two and prioritise them for development.
10. Planning game
During the planning game, a customer and the team determine their scope for the next iteration. The customer comes up with prioritised story cards and the developers produce estimates in the form of an imaginary unit (aka Story Point in Scrum). Developers then create task cards that present the actual development activities needed to implement story cards written by the customer.
11. Regular releases
A release should happen at the end of each iteration – from one to four weeks. Frequent releases enable the customer to return on their investment quickly and get feedback from end customers in shorter cycles.
12. Suitable pace
Pushing your limits, overtiming and working 60-80 hours a week might seem productive in a short term but leads to burnout and fatigue in a long run. XP, much like today’s mindfulness gurus, believes in a work-life balance, finding your suitable pace and level of productivity, and loving yourself.
What’s next?
These 12 extreme programming practices rely on and support each other. The list is robust and might seem overwhelming, especially since XP advocates for adopting all of the practices. Should you adopt all of them or just give up on XP as it requires too much time and discipline to implement? There is no binary answer. As the practice shows, you can still see great benefits with only a few practices in place. After all, Agile is about being agile and finding what works best for you and your teams.
Kateryna Novozhylova
Hi! I'm Kateryna Novozhylova, co-founder at Fractional Teams. I write about product, marketing and tech.
