What is XP?
Extreme Programming evolved from the quick turnaround demands experienced during the dot-com boom of the 1990s. Although the dot-com bubble burst, the benefits of XP were clear and software development has embraced it ever since. As methodologies go, XP can confidently stand on its own two feet. However, the benefits can be witnessed best when part of DevOps deliveries. Mix DevOps/XP with scaled delivery, such as SAFe and it can really take-off – helping get your minimum marketable feature in front of investors and budget holders in staggeringly quick time.
The ethos of XP revolves around rules, values and activities. A lot of software developers like to jump straight to the activities. After all, that’s the doing part. The interesting part. But since you’re reading this, and not coding, I’ll follow the logical sequence here:
There are a few versions of XP rules. Those outlined here are the original 29 created by Don Wells in the early days of XP. Whichever version you refer to, the focus should be on how the rules enable the free & easy attitude of XP to be controlled as an enabler to ensure integration with wider Agile ways of working. As you will see, the Agile mindset runs through all methodologies.
- User stories are written.
- Release planning creates the release schedule.
- Make frequent small releases.
- The project is divided into iterations.
- Iteration planning starts each iteration.
- Give the team a dedicated open work space.
- Set a sustainable pace.
- A stand-up meeting starts each day.
- The project velocity is measured.
- Move people around.
- Fix XP when it breaks.
- Choose a system metaphor.
- Use CRC cards for design sessions.
- Create spike solutions to reduce risk.
- No functionality is added early.
- Refactor whenever and wherever possible.
- The customer is always available.
- Code must be written to agreed standards.
- Code the unit test first.
- All production code is pair programmed.
- Only one pair integrates code at a time.
- Integrate often.
- Set-up a dedicated integration computer.
- Use collective ownership.
- All code must have unit tests
- All code must pass all unit tests before it can be released.
- When a bug is found, tests are created.
- Acceptance tests are run often and the score is published.
Ordinarily, software development would entail a team member (often a Business Analyst) speaking with the end user and capturing what they want the solution to do for them. These days, this would be written-up as user stories with acceptance criteria (if you’re old-school, think requirements and rationale).
However, by the time one or 2 BAs get time with the end-user and capture their ask, take that back to their desks, write-up all the user stories and confirm the acceptance criteria; a good XP duo will have at least the first iteration done and unit tested. How do they do that? Rule number one: The customer is always available. Get the end-user in the same room, or Zoom, as all of the developers and have them explain what they want the solution to do. Not every detail. Just enough for the first iteration and permit the developers to ask as many questions as they see fit. That way every programmer working on the solution will understand exactly the same as everyone else. Even if the end-user changes their mind later, there’s no confusion as to what everyone should be working towards. Communication is key.
For clarity, I’m not saying user stories and acceptance criteria should be ignored. The team should still write these, but they will provide more use at testing than during initial coding.
There’s a trade-off here. The ideal XP scenario is to work towards a Minimum Marketable Feature (MMF), which is even less than the more widely used Minimum Viable Product (MVP) as you are not looking for a saleable product – just evidence your offering works. The aim is to get the simplest code in place, try to break it and iterate from that point until you get what the customer wants.
So what’s the trade-off?
XP, and wider Agile software delivery, at its simplest is: Just Start Coding. To get the best out of this mindset you must be willing to forego the (often misplaced) confidence you would have if your plan stretched further than just today.
Feedback can be broken into 2 categories; automated and human.
Automated feedback comes from testing, mainly unit testing within the dev team and user acceptance testing from the customer. UAT crosses the 2 categories with the end-user providing human feedback in addition to the acceptance test output.
The main human feedback, however, comes from collaboration within the dev team and how the team interacts with the customer. Within the team it is important all members keep themselves in the loop with regards to how the ask and solution are evolving. Customer interaction needs to be managed carefully. Scrum Masters are particularly good at this as developing and maintaining a wealth of stakeholder relationships are a large part of the SM skillset.
XP enthusiasts have a proactive mindset. This is why they work well in DevOps teams. Being comfortable in that mindset takes courage. Courage not to be sidetracked by the old ways of doing things. Traditional programme and project managers like to have an end to end plan. Not having that E2E plan scares them. How do you justify your existence with an ‘Everything will be fine’ attitude?
As traditionally minded change and development personalities move into Agile ways of working they have to face their fears. A gant chart isn’t much use to you when you don’t know what is happening tomorrow, never mind in 6 months time. Embracing a Just Do It attitude is an absolute must when getting the most out of trusted proactive people.
Coders themselves need courage too. Courage to be comfortable knowing their code may need refactored. Courage to understand sunk-costs. Knowing some of that hard-grafted code will need binned if the solution is to meet the end-user’s needs. Courage to battle through, even when complexity is wearing them down and self-doubt kicks-in.
All of these activities, attitudes and more take courage. But the foundation of it all is the XP mindset.
None of the above values would mean anything if there was a lack of respect in the team. Respect covers everyone; self, team-members, end-users and external stakeholders. If leadership can ensure the strategic theme is understood by everyone with a role to play in the solution then each of those role-players have skin in the game.
That sense of responsibility empowers each player to do what is right for themselves, but only if it is right for everyone. As described elsewhere in this article, logical design helps highlight how separate elements of the solution will be integrated. As such, one coder has a responsibility to respect the work of those who delivered before. You don’t break somebody else’s code just to make yours work. You refactor it to make the solution work. If the team is gelled in the way it should be, this issue is likely to rarely occur as integration will be part of continuous discussion.
There’s an old adage that the first activity in any agile project is to start coding. It makes sense. Without code you have no product to improve upon. This is particularly beneficial if a programmer finds it difficult to describe a complex solution. They can code it and other programmers can assess the code and provide feedback. This is an integral mindset in XP, as the remaining activities will elaborate.
Test-driven development (TDD) is what provides confidence in the ability for XP programmers to deliver. Kent Beck (sometimes referred to as the father of XP) wrote in his book, Extreme Programming Explained, that testing is what sets XP apart from other programming mindsets. Flagging a few flaws in early testing can have a significant domino effect when considering the amount of testing you can complete through to final solution delivery. The XP testing goal is simple; try to break the code. Once that ask is satisfied, Acceptance Testing needs to ensure the robust code meets the client’s original requirements, which leads us to…
This can often be the activity many programmers enjoy least. That’s because it means stop doing what you love most and go talk to people who often don’t understand what you do anyway. However, most programmers (the ones you want on your XP features) understand what most change management people don’t. They’re different. Not in a ‘proud to be a geek’ kinda way, but the nature of programming means coders structure their day differently to other project people – and it’s something non-programmers would benefit from learning. Put simply, programmers are makers and others are managers. Managers chop their workdays into half-hour chunks and float from one activity or meeting to another. Makers, on the other hand have little interest in meetings. Quite rightly, they want to get on with developing the solution. To enable this, they typically break their workday into only 2 chunks:
- Before lunch
- After lunch.
If you’re a non-programmer and struggling to get a coder to attend meetings, try asking them for a suggested time. You’ll probably find it is outside of the 2 maker-chunks.
Why design? Why forward plan, when the ethos of agile is to iterate and make the now better?
Well, standalone iteration is great until you have to integrate with another part you’re your system or even a completely separate system. XP within DevOps handles this well, but you don’t necessarily need DevOps to consider design. A good start is a logical data model (LDM). It doesn’t need to be physicalised at this stage. Just use it to see how each handshake occurs and let that steer your scale discussions.
I hope this short article has been of use to you. If you want to learn more about XP, Kent Beck’s book ‘Extreme Programming Explained’ is a great place to start. Just click on the link to be taken to Amazon for a look. More options can be found on my suggested reading page.
For the record, if you use the Amazon link above, I may earn a fee. This is at no additional cost to you. Further details can be found on the disclaimer page.
Please let me know what you think of this article. Feel free to challenge anything you don’t agree with – I’m always happy to listen.