It would be an understatement to describe Agile as being ‘all the rage’ at the moment. The rate of adoption of this development method within the industry is phenomenal. In so doing, it is supplanting traditional waterfall methods quite rapidly.
I think this trend, and the reasons behind it, are worthy of a little analysis.
The clearest distinction between Agile and Waterfall is that Agile is reactive and dynamic whereas Waterfall follows a progressive sequence. What this means in practice is that a waterfall approach relies on the requirements being accurately captured at the outset and there being little change to those requirements during the design and development stages. Agile, on the other hand, offers a process for handling changes to the requirements at any time.
Given that requirements capture is one of the weakest aspects in most software development organisations, it is not hard to see why Agile is seen as the panacea to that dilemma.
Think about what that says for the motivation behind many adoptions of Agile.
Are we fixing a symptom instead of the disease?
If Agile is used because there is an acceptance that requirements capture will be ineffective and therefore some means of managing that is needed, then you are covering up a deficiency in your capabilities that may well still bite you. The question you need to ask is this:
Is it the case that the requirements for this project are genuinely volatile, or is it the case that the customer or us do not clearly understand those requirements?
In most cases, I would argue that it is the latter of those two situations. When experience tells you that projects too often fail through not being fit for purpose, do you;
a) Get better at defining that purpose.
or
b) Learn to iterate into something the customer will accept.
Projects have momentum. It’s like a ski jump. If you want to jump the furthest, you get your skis lined up accurately at the start. If you don’t do that, you’ll end up continually adjusting as you go down the ramp. It’s very unlikely you’ll fly into the air as fast as you might have done and you run the risk of crashing out altogether as your increasing speed gets too much to allow for adjustments.
Image may be NSFW.
Clik here to view.
Of course, not having the ability to steer at all is just as likely to cause you to crash.
Image may be NSFW.
Clik here to view.
Where am I going with all this?
Agile introduces some much-needed capabilities into the process. It recognises that steering is vital to ensuring a good outcome. You cannot 100% rely on the initial requirements capture. Plus, of course, Agile is much more than just a way of accommodating requirements changes. It’s a dynamic way of managing resource and tackling development activities.
Its weakness is that its use can obscure the vital need to properly understand what it is you should be making. No amount of steering will help if you don’t know where you are supposed to be going. There is a great deal of merit in working with the customer at the outset to ensure that both your skis are well aimed before you kick off. That holds as true for a waterfall approach as it does for Agile.
Who wins the death match?
It depends.
· If you have to work within a volatile environment where the requirements keep evolving, then Agile will help you manage that effectively.
· If you are able to 90+% fix the requirements at the outset, a well-executed waterfall strategy will win out every time.
The moral of this story?
HOW you develop something is secondary to understanding WHAT you are developing.
Image may be NSFW.
Clik here to view.
Image may be NSFW.Clik here to view.
