Agile won’t make you faster

December 31, 2011 Luke Walter

A common misperception of what agile is about is speed – specifically, that it makes development faster.  I hear this a lot when asking folks what they’ve heard about agile development – “Agile will make us faster.”  I suppose this is unsurprising given the chronic lateness and cost overrun of the typical software project.  Slowness is the disease, and agile is the cure. Or are they?

Merriam-Webster defines agile as:

1: marked by ready ability to move with quick easy grace <an agile dancer>

2: having a quick resourceful and adaptable character <an agile mind>

The Cambridge Dictionary defines it – in British (not American) English – as:

able to move your body quickly and easily <Monkeys are very agile climbers.> <You need to have agile fingers to do this kind of work.>

Notice that the key word here isn’t ‘fast’, but ‘quick’.  ‘Fast’ is a fraught word, and seems to be what most think will be the new nature of an otherwise traditional project – exhaustive, ill-informed, up-front specifications and all – once we just get agile.  But do we really want the whole train wreck to simply increase speed and arrive sooner?

Agile’s primary benefit isn’t speed but, rather, feedback – between development team members, the development team and the business, and the business and the market.  The most noted effect is greater understanding and insight into what’s working and desired (and what isn’t).  This allows course correction that wouldn’t be possible if you were only hurtling toward a mistaken destination ever faster.  Admittedly, over time and with experience, this difference does lead to a speed-related effect:  more frequent delivery of only the highest-value items.

But what’s delivered to the business and the market isn’t faster in the same sense as what’s expected; You won’t get a whole year’s worth of pre-agile production of code in only three months post-agile. And you wouldn’t want to, would you?  What you might get – with learning, practice, and experience – is a traditional year’s delivery of value in half or a third or even a quarter of the time.  But first you’ll have to get really good at listening to the feedback you elicit, involving your customers, and changing your mind and your plan.  But will you be faster? Which is more important?

Previous Article
Collaboration in the Cloud
Collaboration in the Cloud

In a recent interview our VP/GM, Guy Marion (@guy_marion), spoke with IT Business Edge blogger, Arthur Cole...

Next Article
Bezos’ Petals: Software Development & the “Invisible” Customer Experience
Bezos’ Petals: Software Development & the “Invisible” Customer Experience

As it is that time of year, odds are pretty good that you’ve happened upon the Frank Capra holiday classic,...