Don’t do XP

Steve Freeman offers a counter-argument on his blog entitled Do do XP.

I am beginning to grow weary of the repeated discussions with the many who insist that Scrum doesn’t work without XP.  Scrum works just fine — if applied with an understanding of the values and principles that are at its foundation. The context you implement Scrum in will determine the practices you need to apply.  Scrum in Church will have a different set of good practices to Scrum in Software, and both will be different to Legal Scrum.

XP advocates are quick to blame Scrum for the lack of good development practices in the software industry.  But given the very slow uptake of XP it could be argued (and I shall do so) that in fact XP itself is responsible for the lack of good practice in our industry.

Throughout the 1980’s and 1990’s, as languages improved and lent themselves to better software design, the way people wrote and tested code changed.  In the OO community at large there was a slow, but spreading adoption of ideas such as continuous refactoring, limited responsibility, driving development through writing tests first (TDD), continuous integration, emergent design, the setting of coding standards and even pair programming.  What the XP movement (essentially Kent Beck and a few colleagues) did was to pull all these good practices together into a package, and bundled it up with the the Scrum patterns that Jeff Sutherland had been practicing at Easel Corporation since 1993.  In a sense, this was the first concrete implementation of the Abstract Scrum class [ref].

All of this is good.  But somehow the adoption of these practices didn’t explode as one might have imagined they would. Perhaps it was the name Extreme Programming; perhaps it was the chief, or loudest advocates proclaiming that this was the one truth; perhaps it was management fearing a geek revolution, and working hard to undermine the ideas.  Perhaps it was because, in the end, XP is just another methodology.  I don’t know.  I do know that very few software development teams in the world claim to be (admit to) using XP.

Scrum in the meantime gained enormous traction,.  Not always for the right reasons, of course, but nevertheless a good percentage of adoptions resulted in some improvement to the way software was being built.  And now the XP contingent want a piece of that pie.  They are hungry.

Firstly, lets be clear.  I am absolutely in favor of software development teams using the software development practices best known to produce high quality code leading to valuable products. Why on earth would anyone be opposed to that?  I am less in favor of dumping a package of 12 things on teams and prescribing a method of working that they must all follow. It flies in the face of “people over process” and the principle of self-organization.  In a good Software Scrum implementation the team members would discover good practices for themselves, and the adoption would become personal and meaningful.  That is the kind of improvement I seek.  That some Scrum teams have not yet discovered better ways of working means that the implementation of Scrum needs to be improved, not that team members should be told how to do their work.

Here’s my thought experiment: how many teams would have adopted all the good practices that XP recommends if XP never existed?  I believe many more.  I believe these practices would have come in a fluid way to individuals and teams, as they came to me as a craftsman who cares about what I make.  I have never “done XP” but I have certainly written quality software.  XP’s mistake is to insist on all-or-nothing adoption.  That may not be what the inventors intended, but it is how XP is perceived.  XP may be the cause of people not adopting good practice.  Ironic, isn’t it?

Another point worth noting is that the XP book was written about 12 years ago, since when around 40 new languages have been created [ref].  That means the XP advocates are recommending people use software practices that are potentially up to 12 years out of date — which is about one quarter the life of our entire industry. Scary.  Allow people to discover good practice for themselves and they may come up with practices far more effective than our best minds could produce at the end of the last century.

I urge Scrum coaches to stop talking about XP and start talking about software craftsmanship.  That is what we ultimately seek and desperately need in this industry.  Thankfully, there is now a software craftsmanship movement with its own manifesto [ref] which is slowly gaining support.  Finally, we can begin to reinvent our industry by following good craftsmanship practice rather than new, fix-all methodologies.

Developers: don’t do XP. Implement a common sense framework to surface all the dysfunction of years, to ground you in core human values, and within that learn to be craftsmen again.  Or get out of this industry.