Why you should adopt Extreme Programming practices?

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.