Several weeks ago I re-read Kent Beck’s Extreme Programming white book. It was in preparation for an Agile 101 course that I helped conduct for Agile Vancouver. This was my third time through the book and the first time reading through it in several years. Each time I revisit it, I find I get different things out of it — and this time was no exception.

Reading it this time, I was reminded of all the reasons why I was so taken by the book the first time I read it. The book speaks directly to our fears and failings as software developers. It does so with empathy and the promise of a better way of working. It inspires us to do better by working with our strengths and our weaknesses – our human nature – rather than working against them:

  • we will make mistakes, so let’s make testing central to development (TDD);
  • we will lack courage and cut corners, so let’s jointly hold each other accountable (pairing);
  • we will have trouble coordinating our activities, so let’s plan and integrate frequently (planning game, iterations, continuous integration)

By embracing the human condition rather than ignoring it, XP is truly a humanist approach to building software.

In the intervening eight years since the white book was published, a lot has been written and said on the subject of XP. Much of it seems to be based on a rather loose interpretation of the original work. One of the enduring misconceptions is that XP is a militant, all-or-nothing methodology. The name, of course, doesn’t help. But neither does Bob Martin marching around the stage during his Agile 2008 keynote giving Nazi salutes and putting on a cringe-worthy German accent.

Re-reading the book, I was struck by how Kent Beck advocates an incrementalist approach to adopting XP throughout. Start with your biggest pain point and try out an XP practice that might help; learn from the experience; and iterate. He acknowledges that there is a synergy between the different practices such that the benefit of applying several practices in concert are greater than the impact of applying them individually. But there is no requirement for immediate full-scale adoption.

This is, of course, consistent with the humanist approach. It is hard to take on learning many things simultaneously, figure out how to apply them in context and still reliably deliver value. This is not to mention the challenge of trying to get a team to communicate and coordinate this much simultaneous change. The benefit of having a team focus on making a single change together is easily underestimated.

Two other learnings that I got out of re-reading the book:

  • Maintenance is the natural state of an XP project. Kent Beck describes preproduction as “an unnatural state for a system and should be gotten out of the way as quickly as possible.” This is a radical statement – the wisdom of which is only starting to be acknowledged by the software industry. Most companies have trouble looking beyond their feature-laden first release and have little understanding of how the behemoth they are building will be evolved and supported in production. Google’s perpetual beta is a living embodiment of the ground-shifting power of this idea. My current experience of evolving a product through weekly releases reflects this approach.
  • All methodologies are based on fear – they specify how to keep our fears from being realized. This is an interesting basis for evolving a methodology. One thing that I would like to try is to sit down with a software team and identify the things that we are afraid of (and not afraid of). What steps are we taking or should we take to allay those fears? If the fears don’t match the basis for XP or if the team is afraid of those things that XP is comfortable with then there is likely a contextual/cultural mismatch

In summary, even after 8 years of leading XP teams and 3 times reading through the book, it’s still worth revisiting. If you haven’t read it in a few years, try taking another look.