Last year I met a few people that had never experienced a waterfall project.  Their first software project was with Scrum.   What stood out for me was that these developers had not read Kent Beck’s Extreme Programming.  I also discovered the same for several that were years into their agile development journey – never read the XP book.

Perhaps we are past the sceptical stage, and the notion of working in 2 to 3 week cycles is not considered so extreme any more.  XP may not be as popular as Scrum and Kanban at the moment, but it is still intrinsic to successful agile software development.

I confess that I find a lot of the XP practices are difficult and I have certainly not mastered any.  I think it might be simply that software development is just difficult.  Another reason may be that XP warrants that I change my approach, shifting my attitude to software development quite fundamentally.  That is the extreme part of XP for me, not the 3 week cadence.

Here are a few aspects of XP that I have grown to appreciate over time.

XP makes being a decent human explicit

XP has a lot to offer for the welfare of each person, and for our collective welfare too.  In a software world where we are learning to embrace our diversity, these insights are valuable for nurturing what is still a comparatively young sector.  Certainly, XP offers values.  However, just declaring a set of values does not mean that we live our values.  That’s where XP’s principles and practices kick in.  These exist to nurture those values.  Having a shared set of values and principles is essential in a team, because we use these to help us eliminate options and make decisions.  Value based decisions always seem like choosing the harder option, but the payback is often greater.

XP is about fine grained feedback

XP introduced me to the idea of feedback and made me aware of the theory of constraints – that we just shift problems around when we introduce or remove constraints.  Now we see the rise of lean which focuses on one piece flow, not short time cycles.  That is a different constraint and we have new feedback points like pivoting and waiting until  the last responsible moment.  All these require explicitly designed feedback paths.

Producing a piece of software with one piece flow means that we must bake the feedback into the software we produce.  For example, if we redesign the landing page for a web site, then we need to bake in measuring page views and time spent on the page as part of the release.  Without explicitly thinking about how we receive feedback, we just end up producing a chunk of software that has very little value.  Once we have feedback loops baked in, we are back to observing the shifting of constraints.

XP practices such as continuous integration, collective code ownership, simplifying vigorously, small and frequent releases all aid in building precise feedback loops.  These practices directly support one-piece flow, devops, and continuous delivery.  Yet, most people are unaware that some of these practices are there to increase collaboration.  For example, when there is a problem in the build pipeline, then people will swarm to fix the problem.  It is the high signal conversation after the failure that is valuable.  XP helps increase the signal to noise ratio in our feedback  loops.

XP is not just process centric

As a developer, I am yet to find a set of practices that appeal directly to my work at the most basic level – working with code.  I’ve noticed that many teams that embark on an agile journey tend to focus more on an agile process, than their code base. After a while their code base becomes their biggest bottleneck.  Not obvious is that the potential to regress to a waterfall-like development process is high.  When we have little control over the code base, then we may well reach for more grand planning upfront, less frequent and larger releases, and longer testing cycles.

The code base becoming a bottleneck is not an event that suddenly happens.  It is an accumulative effect.  It sneaks up on us.  Some symptoms are a drop in throughput; it becomes more painful to build, release and deploy; and introducing a new feature needs design contortions.  I’ve referred to this before as “trying to sprint in mud”.   We expend a lot of energy, without going far.

The consequences of a code base out of control is the real kicker.  The code we write affects everyone, not just developers and our customers.  It introduces stress to everyone associated with the software – analysts, managers, customers, family and friends too.  That’s why in XP there are practices that help us keep the code malleable, interwoven with practices that deal with our collective welfare.

With a code base out of control, we can forget  about one piece flow, lean style.  The same goes for continuous delivery and devops too.  Even with the best build pipeline tools, a badly managed code base will not make life easier.  It is like using really bad quality ingredients to make an exquisite meal.

XP keeps a focus on design all the time

XP introduced us to test driven development and continuous refactoring to keep our code bases under control.  Some people use test coverage as measure of that.  I don’t subscribe to coverage as a measure of control.  I prefer weighing up the cost of defects against cost of releasing late.  For example, if getting a feature out means securing a market position, then I would go for lower coverage because releasing late will hurt more than releasing early with defects.  This might be a controversial statement but it is still a viable feedback option.

By the way, it is worth noting that TDD does not yield good designs.  Instead, it raises warnings of problems with our design.  Good design comes from another XP practice of always aiming for simple designs.  Simplicity comes when we gain deep insights into the domain.  Acquiring knowledge takes time – it is a slower feedback loop.  Consequently, achieving a simpler design occurs slower than churning out software at the end of each cycle.

XP allows for code first agile adoption

I prefer to emphasise getting the code base under control as my main target in an agile adoption.  I lean on XP heavily for achieving this goal.  Along the way, the people and process aspects slot in quite naturally.  As the code base is brought under control, it creates breathing room to introduce other non-technical practices.  I’ve found that it is less painful to focus on the code base first, XP style, and slot in other practices along the way.

When I’ve tried it the other way – process before code – I’ve experienced a kind of agility that is only skin deep.  The reason is that the act of adopting the code centric practices requires significant change in developers.  Until developers embrace changes in themselves, in the way they approach coding, the agile adoption will remain superficial.  By “superficial” I mean that it does not penetrate down to the code itself.

Superficial agile is not a bad thing.  I know of some organisations that will benefit from this approach, but only for a while.  For some, that is sufficient.  If we really want to go beyond skin deep agility, then I think it is necessary to reach for XP’s practices that deal with code.  There really is nothing else that deals with writing code in short cycles or one piece.

Should you read Extreme Programming?

My answer is a resounding yes.  It is a wonderful book, written with a lightness and easiness.  Yet is dense with deep insights in every sentence.  The one last aspect of XP that I cherish is that I could ease into to it slowly and deliberately.  I did not have to apply the entire body of work instantaneously, in one huge swoop.  And I am still easing into it.