The return of XP?

An interesting prediction from Kevin Rutherford for 2010: “I predict that 2010 will be the year that eXtreme Programming returns to centre stage.”

I tend to agree with Kevin, while his logic is sound I would offer an alternative rationale for the return of XP. It goes like this...

XP can be viewed from two perspectives: project or engineering practices.

The first of these is basically Scrum. The cognoscenti might debate which came first and which borrowed from which but basically the approach is the same: short time-boxed iterations. Yes Scrum adds in Scrum Masters, Product Owners, self-organizing teams and such but while XP’s description is more basic they have broadly the same approach.

As to engineering practices, there is a growing Software Craftsmanship movement which is aiming to put these back on the agenda. While Scrum has been centre stage in the Agile world many of the engineering practices have been absent. Uncle Bob Martin has been talking about this for a couple of years and I’ve observed it myself (see my post about the Scrum Wall.)

Scrum gained a lot of popularity during 2008 and 2009 but too many of those teams adopted the project management bit without the engineering practices. While that approach can bring benefits it also stores up problems for the future. As more teams take this approach more teams will see these problems and more teams will need to add back the engineering practices and take craftsmanship seriously.

Add engineering practices to a Scrum team and it isn’t very different from XP.

The question Kevin leaves unanswered is: XP 1 or XP 2? For me its Extreme Programming, first edition, “the old testament.”

Now, to extend Kevin’s prediction. I hope we will see the return of “requirements” in 2010, or rather, more focus on “business value” delivery.

The “what are we building?” question has been underplayed in Agile too date. This means the Product Owner, Customer, Business Analysts and/or Product Manager roles (call it what you will) needs to have more attention. Fixing development is the easy bit, the difficult bit is doing the right thing. But, you can only really address that question once you can deliver.