Ayende recently wrote about how most software development processes ignore the actual building of software. Which reminded me of an excellent post written by James Shore over a year ago, and that i commented on as well. What James (and Ayende) are saying is that if you don’t actually take care of the way you build the software, no process can guarantee that any kind of perceived progress in the beginning can be sustained over the long run. Sustainable progress takes effort, and you’ll never keep it up if you don’t put the proper practices in place to enable it.
The sad (and typical) part is that the methodology which makes everything sound easy and prescribes the least amount of effort required is the one that took off the most. Obviously, i’m talking about Scrum. Scrum makes no mention whatsoever about technical practices that are required to enable sustained progress and Scrum proponents will proudly proclaim that it doesn’t need to since it’s about product development instead of software development. You can easily become a certified Scrum master while you might not know anything about real-world software development. In fact, i’ve seen plenty of people boasting that certification on their resume and their linkedin profiles while they really shouldn’t be involved in any kind of professional software development to begin with.
And since Scrum is simple enough for middle-management (you know who i’m talking about… the ones that are usually not competent enough to promote to upper management) to understand, they jump on it as well and before you know it, they’ll be talking about the Scrum concepts as if they actually knew what they’re talking about. Teams and even entire departments in large corporations are told to be ‘agile’ and follow the Scrum rules and concepts for every new project. And they do. And it works great… for a while. We all know what happens after that.
Then take a look at Extreme Programming (XP). It’s been around for a while now. And it unfortunately doesn’t have a good, catchy name. In fact, its name is probably one of the biggest reasons why it never took off the way Scrum did. XP prescribes a lot more than Scrum, and even details the technical practices that you’ll need to enable sustainable progress. And while you don’t need every single one of them, they all provide major benefits and the more of them that you do use, the better off you’ll be. So what is the problem with XP? I never really understood why so many people jumped on Scrum, and now Lean (until the Toyota recalls that is) but never really got into XP. Well yeah i do understand. XP takes more work and effort to understand and apply. And that, my friends, is the price you’ll have to pay for sustainable progress(*).
*: i’m talking about the actual effort and work, not XP in itself