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.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
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.
Kelly.
P.S. Click one of the icons below to join the growing community of people keeping up with this blog by RSS or by email...
10 February 2009 23:12
Thanks for the support! :)
Jurgen
11 February 2009 08:47
Would like to know why SCRUM worked for you - what was it that made it such a success ?
( even without the XP practices )
11 February 2009 12:30
Agreed. Both XP and SCRUM have great ideas, but agility is not itself a methodology (indeed people above process is one of the founding principles).
The trick is to work out which ideas the whole team really need to know about and which are just about improving the software engineering process. Software teams can be many times more agile by turning their skills on themselves - but we don't need to bore the whole project team with the detail. Just do it!
1 March 2009 14:36
Philk - Why has Scrum been so successful for me - with or without the XP engineering practices? The answer, at least in brief, is in my post '10 good reasons to do agile development'. See here:
https://agile-software-development.com/2007/06/10-good-reasons-to-do-agile-development.html
Kelly.
25 March 2009 12:59
If I understand the conclusion of your blog correctly you imply that "Any method could be successful delivering software, and you must pick what you like from any of them to create your own method, but you will only be successful if you are really skilled and experienced"
However you shouldn't adopt Agile methods unless you really understand them.
I am sorry if I misunderstood, but I don't see any consistent or meaningful message in this post. Unless it is perhaps, "Don't blindly adopt Agile methods and expect them to work".
Did I miss it?
Jeff