Agile Myths: You Will Deliver Faster and Cheaper
Probably the two most widely cited sources for the Agile-is-faster-and-cheaper myth are "The Agile Impact Report" from QSMA and "How Agile Projects Measure Up, and What This Means to You" from the Cutter Consortium and written by Michael Mah. Both studies indicate that Agile development results in higher productivity and faster delivery, when compared to industry averages.
The Agile Impact Report concludes that:
- Agile projects are 37% faster to market than industry average
- Agile projects experienced a 16% increase in productivity compared to industry average
The report from the Cutter Consortium highlights two impressive examples of Agile delivery:
"In summary, we have two companies employing two vastly different styles of implementing agile software development and both succeeding in highly dramatic ways. Follett used normal-sized teams and built applications fast, with half the defects, simultaneously saving millions of dollars. BMC emphasised time to market, and while still beating industry averages when it came to cost, achieved a nine-month time-to-market advantage while keeping defects low."
Given this, you might be wondering why I would possibly suggest that faster delivery through Agile is a myth?
I have three reasons.
Firstly, when you look at the data used by these two reports there is, understandably, a spread of results. Many Agile projects are shown to beat the industry average, but plenty don't. There is also a spread in the success of the traditionally run projects: some perform better than the industry average, some worse. All of this means that, for any specific project, Agile may achieve better than average results. But, equally, so might a traditional approach. What's more, the data certainly does not show that a project delivered using Agile is guaranteed to always perform better than the industry average.
Secondly, there are many factors (other than the choice of whether to use Agile) that affect productivity and development speed. In my experience, choice of platform, technology, technical practices and tooling all have a big impact on productivity. More important still is how skilful and engaged the people working on a project are. Indeed Steve McConnell has often re-iterated that there is at least a 10 to 1 difference in productivity between different developers and Jim McCarthy has been a long standing advocate of the importance of engagement, once saying:
"Generally, although the problem feels like too few people are on a project, it is usually the case that too little of the many people assigned to the project is actually engaged."
Thirdly, to think that a key benefit of Agile is that you can deliver the same features and functionality faster is to miss the point. What Agile does do is try to deliver more value, more quickly.
A simple way that this is achieved is by delivering working software frequently in small increments. This increases the overall value in a way that I first saw described by Bruce P Henry in his post on how Multi-Tasking is Killing Your Business. Here is a very simple example (which I have also shown graphically):
Let's say you are writing some software that will generate £1m of revenue per year and it takes 2 years to build. After 5 years you will have generated £3m of revenue (because you spent 2 years building the solution followed by 3 years of getting value from it). Now take the very simple step of breaking this into two deliveries, each of which is capable of generating £0.5m of revenue per year and each of which takes a year to develop. The total revenue generated goes up to £3.5m and you are starting to get a return on investment 1 year earlier. Now imagine the (not unlikely) scenario that 20% of the development effort can yield 80% of the revenue. Now the 5 year total goes up to £4.2m and you start to get a return after just 5 months. This simple change in approach has delivered 40% more value over 5 years.
A more subtle way that Agile delivers more value is by ensuring that what is delivered is actually, wait for it, valuable. As Scott Sehlhorst put it in this post:
"If an agile team builds me a better dresser faster than a waterfall team builds me a not-as-nice dresser, I’m not better off if what I actually needed was a coffee table...Getting faster is nice, as long as you’re getting faster at building the right product."
And Agile improves your chance of building the right product by turning hypothetical value into real value as soon as possible; agile teams uncover what delivers the most value by building something, getting feedback and then iterating.
So that is why I think that faster delivery is an Agile myth. The data does not show that all Agile projects deliver faster (although most do). Many factors affect productivity which are independent of an Agile or non-Agile choice. Perhaps most importantly, Agile is not about delivering the same thing more quickly, but delivering more value faster. And I couldn't summarise all of this any better than Luke Walter, who put it this way here:
"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."