XP2 and the real problem in software development

I went to talk given by Rachel Davies last night. This was organised by the BCS SPA group who hold monthly sessions in London. Although I’m not a fan of the BCS (British Computer Society) the SPA group is quite interesting and active.

(As usual some of the most interesting conversations are held in the pub afterward so its always worth going for a pint.)

Rachel was talking about Kent Beck’s second edition of Extreme Programming Explained book. I have to admit that while I’ve had this book on my desk for several months I’ve not read it. Having seen Rachel’s very good presentation I have to say I’ll probably not read the book.

Its no secret that I’m not a fan of XP – or at least XP version 1. Don’t get me wrong, there is a lot of good stuff in there but I’ve never been happy with Kent’s “Do this, do everything I say or don’t call it XP”. I think every organization and team are different and the important thing to do is to create your own system that works for you.

So, while I’m a big fan of the Agile development movement I’m not fanatical about any of the methodologies. I view Agile as a collection of tools you can use to think about problems and devise solutions. Some of the tools can be used “out of the box” other need tailoring.

The best thing about the first edition of XP was that was a “call to arms” (as my friend Kevlin Henney says). The book describes an alternative way to live your life, an ideal, it rallied people and made them think “things can be different” – it offered an alternative identity, it said “developers are really important, don’t devalue coding.”

From what I hear about the second book its a bit of a kitchen sink. It doesn’t say no to anything, if it sounds like a good idea Kent’s included it. Its probably unfair to comment on a book I haven’t read so I won’t say any more.

If you are interested in XP, Agile or Lean development the best book you can read is Poppendieck and Poppendieck.

However, at the end of the evening I left with the same thoughts as I always have after discussing XP, Lean, Agile, software development process, etc. etc.

We know how to do it. There are plenty of books which tell us how, plenty of people who know the techniques, people who’ve don’t. Doing isn’t the hard bit.

The hard bit is: how do you change? How do you move from here to there.

This is the real problem and its hard. The “software development community thinkers” haven’t really addressed change.

This is also sad because IT is actually all about change. When you develop a piece of software and it gets installed you change the people who use it. You change the organization, you change the problem. In fact, the objective of introducing a new IT system is usually to introduce change. Nobody really wants to run SAP, they want to change their production department and SAP is merely the way to do that.

We often hear about software development failures – the figures differ but the message is usually the same “most software projects fail.” Truth is, most change initiatives fail, since software projects are about change is it really surprising that failure is so common?