Recently I’ve been thinking about XP practices, such as TDD, and why they aren’t the normal practices done everyday.
Luckily, the nice people at XP Manchester let me run a 5 Why’s session in order to crowd source some great ideas.
Disclaimer: I’ve written up the session but in case I’ve remembered something incorrectly, I apologise to the group!
What is Extreme Programming?
Extreme programming is an agile methodology developed by Kent Beck. By taking practices that work well and taking them to the “extreme”, software development teams can deliver quality software in challenging environments.
For example, code reviews can help to increase code quality and share learnings by getting more members of the team to look at the code. Then constantly reviewing the code via pair programming can improve the value and frequency of those benefits.
You can check out more information on Extreme Programming here.
XP Manchester
If you’re ever in the Manchester area I definitely recommend checking out the XP Manchester user group. For more information on the kind of sessions that have been run there, you can check out their website here.
Over the years I’ve learnt a load from the XP Manchester user group. So I knew that by proposing the question “Why aren’t XP practices the norm?” to the group, I’d get some excellent answers and thoughts.
The session
Thanks to the pandemic and everyone being in lockdown, XP Manchester is currently being held over Zoom. I’d normally run a 5 Whys session using a whiteboard, but Miro came to the rescue.
Using the 5 Whys format, as a group we tried to answer the question “Why aren’t XP practices such as TDD more widely adopted?”. Then for each answer, we would ask Why again. It’s usually pretty rare there is a silver bullet answer to a problem. So by repeating Why 5 times hopefully we should be able to break the problem down small enough to try and get some actionable ideas.
The XP Manchester crowd did not disappoint. The conversations around possible blockers to putting XP practices in to place was extremely interesting. Below you can see the output of the 5 Whys session.
XP Values
While the main question we were discussing was based around why aren’t the XP practices the default practices in use, the XP values were discussed as well.
There are 5 main values in Extreme Programming;
- Simplicity
- Communication
- Feedback
- Respect
- Courage
This post isn’t to delve in to values, if you want to read more around the XP values, you can do so here.
It was nice to see that in the discussion we struggled to imagine a scenario where the XP values weren’t good values to try and apply.
XP Practices
Some of the practices from XP include;
- Test driven development
- Pair programming
- Continuous integration
- Refactoring
Again, this post isn’t for delving in to those practices, but why aren’t they always used. For more information on XP practices, you can check out this post.
These are some of the practices that seem to be generally accepted that they are good practices to follow, but for whatever reasons, they aren’t always put in to action.
Some ideas
There were some very interesting ideas from the session as to why XP practices are not always put in to action. Far too many ideas to dig in to each one in the session, but definitely some points I’ll be taking away to think about. Such as, maybe some people haven’t met any XP advocates, Extreme Programming itself is pretty old, and some of the practices are difficult.
One of the main ideas that we dug deeper into was that some people don’t see the value in them. One of the answers to asking why again was that in some scenarios quality isn’t always the largest driving factor. I hope that any case where quality is sacrificed for speed is done so intentionally for extremely short time scales. Otherwise that lack of quality will likely end up costing more in time anyway.
The fact that it is hard to prove the value of following XP practices was another branch of the discussion. A lack of useful metrics was one possible factor to this. Metrics being difficult to define and measure is not a problem exclusive to XP, but it is definitely a hard problem to solve.
When exploring why it’s hard to prove the value of XP practices, the perceived cost of implementing them was touched upon. A lot of the practices are skills that take time to learn and build on.
Actions
Just as I’d hoped, by throwing the question out to the XP Manchester group, I’ve got some great ideas to take away and try make XP easier to implement.
Definition of success
The idea that sometimes quality isn’t the only definition of success really got me thinking about the impact of Extreme Programming on software products. I think following the XP values of communication and courage would help to clearly state with the wider team what success looks like. If quality isn’t the main definition, it’ll be super important to talk about timescales and what the longer term definition of success looks like.
Investment
The conversation at XP Manchester reminded me that for a team to learn new skills takes an investment. Again, leaning on the XP values should be a big help here. By clear communication of the benefits and costs of XP while ensuring we give and seek feedback, we should be in a better place to get that investment.
Embody the values
I thought going in to the session I’d be able to steal everyone elses great ideas about how they’d been able to implement XP practices. However, I think what I took away was even better. Focus on the values. The more I think about the XP values, the easier I think it’ll be to implement the practices.