Skip to main content
Enterprise Agile Planning icon with arrows

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Dec 30, 2011 — Enterprise Agile Planning expert

Agile won’t make you faster

Enterprise Agile Planning

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?

More from the Blog

View more Government Cloud
Apr 12, 2022 Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us