What is Extreme Programming?

Extreme programming (XP) might conjure up images of tech-bros coding in precarious situations and drawling ‘duuuuude’ a lot, but it’s actually a potentially transformative methodology for software development and digital transformation projects.

XP is a member of the Agile family and, like its brothers and sisters, aims to provide iterative and frequent small releases throughout the project. As with all Agile methodologies, XP also places an emphasis on allowing team members and customers to review progress as they go, with regular feedback sessions.

However, there is a twist. XP has a specific focus on simplicity, teamwork, and quality of environment for the development team. Indeed, the Agile Alliance defines XP as:

“Extreme Programming (XP) is an agile software development framework that aims to produce higher quality software, and higher quality of life for the development team.”

How Does It Differ from Other Agile Methodologies?

Where XP differs most radically from other agile methodologies is in its adherence to a set of five values, upon which its success ultimately rests:

1.Simplicity

XP always begins with the question: “what is the simplest thing that will work?” This helps to prevent waste and makes the system easier to maintain, support and, if needs be, revise.

2.Communication

XP recognises that any software development team is only as effective as the sum of its parts, so stresses the importance of communication and the transfer of knowledge between team members.

3.Feedback

Through constant customer feedback throughout the development process, teams can identify issues, revise ideas and make improvements as they go. This has the additional benefit of fostering simple design: the team build something, review it with the customer, make improvements and move onto the next step — avoiding the usual jumble of palliative fixes and afterthoughts that go into many dev projects.

4.Courage

No, you haven’t read that wrong; courage is a fundamental element of XP. Teams need courage to raise organisational issues that reduce effectiveness, courage to stop doing something that isn’t working and courage to accept feedback – especially when that feedback is difficult to swallow.

5.Respect 

Finally, team members need to respect each other in order to communicate, implement feedback and work together to design simple solutions. This fifth value is actually created through the Agile process, as with each small success respect among team members grows and eventually becomes self-perpetuating.

Alongside these bedrock values, XP also relies on a set of development practices aimed at mitigating the risks inherent in software development. You can find out more about what each practice entails here, but practices include:

• Continuous integration
• Sitting together
• Informative workspace
• Utilising the whole team
• Energised work
• Pair-programming
• Product or function stories
• Weekly cycle (for iterative changes)
• Quarterly cycle (for releases)
• Slack
• Ten-minute-builds
• Test-first programming
• Incremental design

When Should You Use It?

Unlike other Agile methodologies XP isn’t well suited to general use. XP was created to address those projects that are subject to frequently changing requirements. It might be that your customer doesn’t have a clear idea of what they want, or it might be that the system is one where functionality is expected to change every few months. In both cases XP, with its focus on teamwork, is likely to succeed where other methodologies do not.

XP is also great for high-risk projects. For example, if your customer needs a project delivered urgently or by a specific date. Likewise, projects that use new technology or offer a new challenge to your development team bring with them a degree of risk. The values and practices set out by XP are all geared towards mitigating risk, making it perfect for tackling exactly this type of problem.

It’s also worth noting that XP works best in small groups of programmers, ideally between 2 and 15 — although this certainly isn’t set in stone, there have been instances of successful XP projects with a staff of 30. Because XP relies on a small, tight-knit team, the bigger the group the more you risk diluting its potency — besides, projects with dynamic requirements often work better with fewer hands anyway.

The final requirement for an XP- suitable project is testability. One of the key tenets of XP is programmers’ ability to iteratively test, review and improve the system — without it, XP’s values-based method is powerless to deliver.

While XP has huge potential for the development stage of a project, it can run into problems when other teams within your business are involved. For example, operations teams rarely work at the same pace as their colleagues in development, which can cause bottlenecks and delays to the delivery of the project when software is passed across to them. This risks undoing much of the good work XP does in getting software delivered quickly. 

Perhaps the best way to overcome this is to use an Agile methodology like XP in conjunction with DevOps. The two share common values and principles and DevOps can work well as an extension of Agile for non-development teams. In fact, DevOps was largely conceived to counter the gaps left by Agile being a development based methodology and using the two together can help you reap the same speed and quality benefits across departments. To learn more about implementing DevOps in your business, download our guide.