Why incremental development is better - An ROI perspective

After much prodding from Jeff McKenna, I finally got around to reading “Software By Numbers” by Mark Denne and Jane Cleland-Huang.  It’s an interesting read that focuses the software development process on delivering value to customers.  Denne and Cleland-Huang introduce minimum marketable feature (MMF).  The MMF represents the smallest possible decomposition of a feature/capability to which business value can be attributed.  The authors go further to define a software development value chain that is designed to optimize value delivery to the customer.  While I of course have some concerns with the model, I found the underlying financially driven approach very interesting.  It aligned very well with prior work that I’ve done in Project and Portfolio Management (PPM).

Software by Numbers got me thinking about Agile.   Specifically around incremental development and how it has an inherent advantages over traditional methods in delivering value to customers.  I wanted to push on this a bit so I built an ROI/NPV (return on investment; net present value) calculator.  These are well-established metrics for measuring how projects deliver value to the business and for evaluating various investment choices.   Check out the hyperlinks above for more information on NPV and ROI.  So I scraped the rust off my business math skills and built an ROI calculator using Excel.  The results are pretty much what I intuitively excepted.   Here they are:

Some assumptions made with the calculations are:

• Execution of the agile and traditional projects are assumed to be “perfect”.  The planned value is delivered on
• The total monetized value delivered by the agile and traditional team is $1 million.
• Value is not immediately realized on feature delivery.  The traditional project value is realized linearly the first year after the project completes.  Agile project value is fully realized within four months of delivery.
• There are 10 resources on the team with a loaded annual salary of $125,000.
• After all value is delivered, maintenance costs of 20% per year are incurred for years two and three.  That is, ongoing costs are reduced by 80%.  This assumes no major development work is delivered after year one.
• Cost of capital is assumed to be 15%

Its interesting also to look at the payback period.  The payback period basically states how long it will take to recoup your investment based on benefits received as a result of the project.  With the incremental/agile approach you achieve payback in half the time (14 versus 30 months)!  The graph below shows cumulative net benefits.  The payback period is basically the interval prior to lines crossing $0 on the y axis.  Each interval on the y axis on the chart below represents two months.

So what does this all tell us?  Deliver value to your customers early and often!  The benefits of agile’s incremental delivery approach are very quantifiable.  I'll be blogging more about agile ROI in the future.  The things I'll be exploring will be the impacts of failure and scale on agile development, how it can impact ROI, and how you can mitigate the risks!

You can download the excel spreadsheet for this ROI/NPV calculator here.

Comments

[Giora Morein]

I'm having trouble understanding something in the spreadsheet calculation. In the Agile ROI calculation in the period 1, you already have the fully maximized Benefit (1M/6 periods). This is the same value you are realizing in the Traditional ROI sheet for period 7 - the first period that you have realized benefit in the traditional model. Surely the benefits realization rate of an Agile project in the first 2 months would not be the same as in later periods. I would imagine that despite its shortcomings, the benefit that a traditional project can realize when releasing after a year would be higher than an Agile project releasing after 1-2 months. It seems that what your calculations are really doing are comparing 2 projects with identical benefit realization rates with one taking twice as long as another - which obviously would have a lower ROI and payback period. I think your assumptions should account for the fact that in earlier releases on Agile projects, the benefits delivered are partial - and therefore deliver only partial value.

Giora Morein

[Giora Morein]

On second look - I see in the Agile ROI model you are in fact incrementing each period's value by a fraction of it's maximum value. I understand much better now.

[John Scumniotales]

Nice debugging. I find understanding another author's spreadsheet to be far more difficult than understanding another developer's code. The analysis is quite simplistic. Its mostly about the time value of money. Thanks for the feedback. -j.

[Giora Morein]

You might also be applying the cost of capital to each period, rather then the annualized value. You should probably be discounting by 15%/6 for each period. You still get the same basic results but not quite as dramatic differences.

[Dennis Stevens]

Really nice job. This is the same lesson we teach our kids about saving money early in their lives. While I agree on the problem with the discount rate, I have a couple of other things to mention that are valid in the real world at the Enterprise level.

1. Some features are more valuable than other features. If managed well, your early return will probably be higher as each incremental feature is not viewed as more valuable to the market. Higher earlier benefit actually creates a bigger spread.

2. If managed well, the overall fit to market of the product after the first year will be better because you have real feedback from customers. Your quality of service will be better because you have practiced the processes. Therefore your maximum realized benefit would potentially be higher in the second year then traditional.

3. Assuming you manage a multi-project environment well, there is a far bigger difference. In the agile model, you can get two products launched in the first year for the same cumulative cash outflow as the one product in the traditional model. In reality, there is some shared cost and infrastructure that will reduce costs (although not initial speed).

4. The Agile model greatly reduces risk to the business. The ability to go after two markets, the ability to be more responsive to changes in markets, the ability to expedite new opportunities without abandoning work in process, the ability to verify demand earlier, etc. all reduce risk. Adding risk weighting to this model creates an even bigger gap.

It would be fun to build out an Enterprise model building out an assumptions page to play with the impact of these four points.

[Chad Albrecht]

Great post! See my related posts here:

The Dollar Value of SaaS Features
http://blog.chadalbrecht.com/post.aspx?id=10a5a8b1-2bb6-4fef-b612-5bae80e121fe

and here:

PMBOK, Agile & TOC: Planning the Project – Part 1, NPV & IRR
http://blog.chadalbrecht.com/post.aspx?id=ad07676e-daf9-4e55-a933-c6c0bf3ea3f8