Agile won’t make you faster

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?

Luke Walter

Luke Walter is a Certified Scrum Trainer® and Agile Coach, helping organizations maximize value delivery using the Scrum framework and Agile development practices. He guides senior management, development, and operations through the challenges intrinsic to agile adoptions, enabling them to adopt more meaningful measures of progress and realign for effectiveness. A 9-year Scrum veteran with over 8000 hours logged on high-performing Scrum teams, he brings an uncommon depth of real-world agile experience to organizations seeking to transcend procedural and cultural barriers to success.

Posted in Agile

Leave a Reply

Your email address will not be published. Required fields are marked *