Even that term is a meme. How about Extreme Programming (XP) vs everything else? There’s been no end of opinion on the topic, and it came up again in conversation with a colleague. So here’s my take on it. XP rocks, the rest are varying degrees of marketing rubbish. Succinct, no? :)

Ok, that’s not entirely fair. Some other forms and practices of agile development do have their merits, I just have a marked preference for the practices all gathered together under the name XP.

A longer version. Our job in IT is to deliver business function, ideally on time and to budget. Unfortunately our industry is one where it is acceptable to have varying degrees of quality. I do not agree with that, but let’s be honest - bad software is everywhere and generally there isn’t much real incentive to not make more of it.

I’m not going to detail the principles and practices of XP, Kent Beck and co. described it better than I ever could. If you really want to understand it, read the Extreme Programming Explained series of books. They are so worth your time - changed my life :)

Anyway, XP is simply a set of development practices which fit really well together. They are geared to producing top quality software in a sustainable, maintainable and fast manner. Yes I’m a fanboy, but that doesn’t make it less true.

It’s not all roses though, there are some areas just not suited to XP:

  • Anything requiring upfront long term design of specifications, like embedded systems is problematic. You can still do all the XP coding practices, but you don’t get the agile planning flexibility. Still worth doing though.

  • It doesn’t work well with remote teams. XP is communication heavy - there is constant communication within a pair and within a team. That can be done remotely, but not as well. Not being able to have all modes of communication that sitting beside someone provides will slow you down. That’s not even counting timezone differences.

  • Finally, XP requires a team of dedicated, conscientious, careful developers. There is no room for slacking off or cowboys. A couple of those can destroy an XP team, and standard advice is to remove them.

Note I didn’t say that the developers all needed to be experienced. Pairing means that the experienced developers in the team get to spread their domain and coding knowledge rapidly to the rest of the team. The less experienced developers just have to be ready to learn. Pairing is an excellent teaching tool.

What XP is not - move fast and break things. This is absolutely not XP. The entire point of XP is that it maintains a stable, production ready system at all times. Breaking things is a major no-no. In fact, if this ever does happen within an XP team everybody stops everything else until the bug or breakage is fixed. Getting a stable system is the number one priority.

So, back to the original topic. Ever since agile practices like XP became popular enough to become management buzzwords, everyone and their dog wanted to cash in on this new lucrative consultancy income. There are now so many variants of Agile, each with their own terminology, training courses, certifications, consultancies and no end of marketing. From a development perspective, they don’t add much, and some look suspiciously non-agile.

Many are targetted at making agile teams appear less scary to product and management, generally by making them appear non-agile in everything but name. To be honest, it doesn’t matter. What happens outside a team is less important. You can take your SAFe (just an example) team plan for a PI, get the stories from it, and then work XP within the team. If product and management don’t want to make use of the flexibility and agileness in planning that an XP team can give them, that’s on them. Within the team you can still go full-on XP. It’s so much more fun than not. :)

Shared at https://www.linkedin.com/pulse/agile-vs-donal-stewart