Pat’s Point of View

I like analogies, metaphors and similes. They can help transfer understanding from one domain, or concept, to another. Here’s an analogy that I think helps illustrate the pros and cons of a agile software development approach, using an explanation of a popular automotive safety feature: Anti-skid Braking System (ABS).

A common misconception is that a vehicle equipped with ABS will stop more quickly than a vehicle without ABS. This is incorrect. All else being equal, when stopping in a straight line, ABS will necessarily cause the vehicle to take longer to come to a stop, because of the very nature of ABS. When the driver of a vehicle fitted with ABS applies the brakes very hard, a computer will continuously turn the brakes on and off very quickly, such that the wheels continue to turn some of the time and thus do not skid (well, not as much). The driver maintains the ability to steer whilst braking, because he or she can steer during those moments when the brakes are off. Thus you can brake very hard but still steer your way around objects, maintaining control of the vehicle.

Without ABS, when the driver brakes very hard, the wheels would stop turning, causing the wheels to “lock up” and skid, making steering impossible. This is when maximum friction occurs, and hence when the maximum braking force is in effect. So you can stop most quickly without ABS, but you won’t be able to steer and will more than likely lose control of the vehicle and crash. All things considered, it’s better to sacrifice some braking force in order to have control of the vehicle. Hence the popularity of ABS.

I see striking similarities between this and the argument over agile software development methodology. Agile will not make the project go quicker! In fact it might take longer to finish the project (but when exactly you “finish” is contentious). Just as an ABS-equipped vehicle can steer while braking, a project using an agile approach will be—as the name suggests—more agile, maintaining the ability to control the direction of travel. Collectively, the project team can adjust their aim if they have wandered off on a tangent, say for example if the product strays from meeting core objectives. By bringing forward design and iterating quite quickly, the end result of the project can be kept in focus and development can be kept on target (incidentally this is where agile can be very beneficial for UCD and vice versa). Agile allows you to not crash head-long into failure!

However, what an agile approach will not do is shorten your project. It’s annoying when people talk about “adopting agile” in order to “deliver in shorter timeframes”. They’re confusing agility and speed. As far as I’m concerned the only thing being delivered earlier are the early design prototypes. The final deliverable is not necessarily completed any quicker than with a good old fashioned waterfall approach, because during the iterations the design will evolve and some stuff won’t be used (either because it’s taking us off target or because it doesn’t work). In return for your agility, you must accept that there may be wastage or re-work caused by each iteration and that you might not finish any sooner.

What say ye?

[Photo source: DervMan]

This entry was posted on Tuesday, June 9th, 2009 at 5:56 pm and is filed under Automotive, Ramblings, Web design. If you enjoyed this post, you might also like to leave a comment, find out more about me or follow @patrickkennedy on Twitter.

You can also trackback from your own site or follow any comments made on this post through the RSS 2.0 feed.