Nowadays everyone is agile. Or at least they say. Most organisations use Scrum. Or they claim to do it, while still doing waterfall. But why is the industry so focused on Scrum? What happened to eXtreme Programming? Why did we loose the XP practices? Are they too extreme?
The first agile methodology I heard of was eXtreme Programming back in 2001 when I was a CS student and read the eXtreme Programming Explained book by Kent Beck (published 1999). I remember reading about the ideas of pair programming, refactoring, test driven development and simple/evolutionary design and thinking that this is the future. The planning game and user story for requirements parts was nothing I payed that much attention to – I was completely focused on the code writing at that time.
Scrum is a few years older than XP, being launched in 1995 by Jeff Sutherland and Ken Schwaber. If you’re a regular reader of my blog you know that I have thought and written quite a lot about Scrum but very little about XP. The reason is that I’ve been quite focused on the management view of agile projects in order to get the customer interaction working. While XP is a bit vague (and too extreme with a customer full time on the team), Scrum offers a set of rules that is easy to get started with and easy to explain to the customer.
I think that I’m not the only one being dragged to Scrum because of the relative ease of getting started combined with the focus on the relation with the customer. Add to that the fact that most managers that are involved in methodology selection understand the core Scrum process, but without a strong foundation in development most XP practices make no sense. From a “marketing to management” perspective Scrum is easier to argue for and has become the de facto standard agile methodology.
But I think that we lost something along the way. We lost the technical XP practices that are an important foundation for the ability to be agile. Without those technical practices, can a Scrum team really become truly agile?