The Decline and Fall of Agilists

Jurgen Appelo has written a really interesting blog post called The Decline and Fall of Agilists. Well, it’s more of rant really, and it’s generated quite a debate!

Personally I like the agile engineering practices in eXtreme Programming (XP). They make a lot of sense to me.

But, in my last job, we implemented Scrum in a development group of over 100 people, without really implementing any XP practices until much later on. We saw phenominal success using Scrum without XP. A real transformation in our delivery. And a massive improvement in our business relationships.

One of the things I really like about Scrum is its simplicity. The fact you can implement it pretty quickly, straight over the top of whatever software engineering processes you already have in place.

That’s because Scrum is an agile management methodology, and doesn’t prescribe how you should approach the tasks.

Now you could certainly argue that we might have been even more successful if we had also implemented XP. Maybe that’s true. eXtreme Programming evangelists joke that “Scrum is just XP without the technical practices that make it work”.

Quite a funny statement, when said tongue in cheek. But in my experience it is simply wrong.

So thus far, I am with Jurgen.

I think that’s because our situation in my last job was like Jurgen’s example of chaos versus order. In our case we were moving from complete chaos. Scrum allowed us to put some lightweight, structured process (i.e. order) into place fairly quickly, and get things much more organised, more transparent, more collaborative, and therefore more successful.

But how do I feel about the argument (sorry, debate) about prescriptive processes versus adaptive ones? I’ve touched on this in my last blog post, Agile Processes Are Meant To Be Adaptive (But Only When You’re Ready).

It’s great that agile is meant to be adaptive. It’s a fundamental principle and it’s the very meaning of the word. It’s great that continuous improvement is built into Scrum, making it a repeatable part of the process. And I love the fact that Scrum does not attempt to prescribe anything about how the product should be engineered.

In my view, there are clearly some agile engineering practices in XP that make it much more practical to work in short iterations without compromising quality. But that decision – the decision about what level of engineering is appropriate – does depend on the context, and a team or organisation’s readiness to adopt.

I also love the fact that XP’ers are so enthusiastic about the method. I see a real sense of craft when I see the passion behind XP’ers comments. But it often comes across as a bit religious. Almost like the developers uprising against the establishment. “You must do this or you will fail”. Technical perfection over commercial priority. Almost sneering at anyone who doesn’t do XP and dares to call themselves agile. I really don’t think that’s good for the cause.

eXtreme Programming is just one agile methodology. A good one, I think, but just one. There are other methodologies that share the same agile principles. There are people doing Scrum and seeing great success from agile. There are people doing Scrum and XP combined, as they are very complementary, and seeing great success. There are people doing DSDM and seeing great success. There are even people following no process in particular, but working to the same agile principles, and seeing great success.

Come to think of it, there are even people doing waterfall using PRINCE2 and seeing great success 🙂

The real trick, actually, is taking the best of all these methods and combining them in a unique way that fits your unique circumstances.

But that requires a great deal of skill and experience. And until a team has this experience, they may well be better off following a presribed process. Until you have this experience, and really understand *why* agile works, you’re not really in a good position to adapt it.