Total Cost of Ownership (TCO) is lower in agile development

The total cost of ownership of an application is much lower while developed using agile methods as compared to traditional methods. If the total cost of ownership of an application in traditional way is $10 million, by doing it the agile way, it may very well be only half of that or even less. There are scientific studies to prove that with data points, but here is an attempt to explain the reasons behind this advantage.

 Idea & Illustration: Courtesy Rakesh Dahiya

If you notice, the total cost of development is shown as almost the same between developing the traditional way and developing the agile way. Though agile gives you early value and higher productivity during development, there is also an upfront investment on quality (test driven development, acceptance test automation, continuous refactoring etc. ) which evens out the development cost. In agile, there is more investment on prevention of bugs and in traditional, there tends to be more cost of correction (time and effort spent during integration, UAT, regression test etc.). Overall, it would be fair to say that the development cost would be pretty much the same.

During the development phase, if you see the technical debt in traditional shoots up because suddenly you end up with a big-bang integration, UAT patches and architecture and design that is more accommodated for the surprises that happened during go live. The code quality and performance would have hardly tested enough while in agile you are dealing with a code base that is rigorously tested, measured, refactored and monitored on a daily basis for code quality, test coverage, performance, complexity, architecture and design scalability, etc.

If you look at the business value during the development phase, while in agile you obviously realize constant business value, in traditional you realize the value only in the end. Due to the fact that you may have been disconnected from the business during the development phase, and may have built many features that are not priority for the business anymore, the business value in traditional tends to be lower than when you do the agile way. Simple reason – you only build what is absolutely the need of the hour.

The real game changer in $$$ is what happens during post-production, i.e. the maintenance phase. Sadly this part is what is missed out most of the time while comparing business value of agile vs. traditional.

By the time the application is rolled out, in a traditional scenario, there is a huge amount of requests that surge in. Mostly due to missing requirements, new business needs that had to wait during the development phase, immediate business priorities, misunderstood requirements, etc. The technical debt surges upwards and most of the time, the system gets patched up to accommodate all these requirements as part of the post-rollout support. There are no refactoring practices and the system accumulates technical debt year on year making it difficult to manage. Even small changes become way too expensive. The high cost and high technical debt that you see in the diagram is a direct result of this scenario. As for the diminishing business value, the system goes into a legacy mode much earlier in its intended life cycle and finding it hard to remove unwanted features, clean up, or scale up making it expensive to maintain and all this due to the way in which it was built. The ‘clean code’ focus that was missed out during development proves expensive during maintenance.


In agile applications, the maintenance is normally a breeze as compared to traditional. Due to the inherent focus on preventive measures like clean code, scalable and evolving design, service oriented architecture, acceptance test automation; the application is way sturdier and will scale much easier and faster during maintenance phase. All the investments done during the development phase on product quality will pay off as savings during maintenance phase. You don’t need an army of support staff to enhance an agile application. The throughput of a feature will be much faster as compared to traditional due to the same reason and while you may need 10 people to maintain a traditional application, you will find that you can manage a similar agile application with 3 or 4 agile developers producing much more business value in a shorter time frame.

It is for us to decide how we would rather invest – To build a great clean product which will sustain for many years with lesser TCO, or to be short-sighted and keep investing $$$ year on year just to feed a mammoth built the wrong way.

Some quick facts about Agile TCO and business value comparison:

As compared to traditional methods, Agile gives productivity 10 to 20 times higher and quality 19 times higher which reduces the development cost (due to productivity) and maintenance cost (due to less number of defects)

Agile gives you the TCO advantage of approximately $ 4 million savings per 1000 lines of code

Agile gives exponentially high cost/benefit ratio, ROI, NPV, ROA and early break-even as compared to other methods

Ref slides 9 to 15 on our very popular slideshare :


The Business Value of Agile Software Methods by Dr.FRico ,Dr.H Sayani, Dr.S Sone

Benediktsson, O., & Dalcher, D. (2005). Estimating size in incremental software development projects. Journal of Engineering Manufacture, 152(6), 253-259

Never miss a story!

Sign up for our newsletter and get the best stories delivered to your inbox.

Co-founder of People10, a 'total agile' software development and consulting company


  1. ZaheerReplyJune 28, 2012 at 5:41 am 

    From stakeholder/sponsors standpoint, in order to measure the business benefit relisation in terms of revenue, cost savings and profit, the ROI from typical project lifecycle methodology can only be realised post final release.

    Agile in its inherent nature allows to foucus on realizing more business value in the early releases (rather with every release if planned properly) which in turn govern and manage the TCO effectively for stakeholders/sponsors.

    • Bob AllenReplyJuly 14, 2012 at 4:16 pm 

      Good point Zaheer, but it gets better. While using Agile practices to get features into the marketplace much earlier can result in earlier revenue or other market benefit, it can also flop earlier thereby providing the opportunity to learn before shooting the entire budget on what proves to be a bad idea.

      The ideal situation is where what you release into the wild is structured so that if it fails, it can offer at least hints on why it fails. The value under this circumstance is in what you can learn.

  2. SyamReplyJuly 4, 2012 at 5:11 am 

    Unfortunately, most software firms follow the ‘traditional’ approach because they really want to keep the applications complicated enough to milk their customers more in the future! I hope that customers will start realizing it soon.

  3. Nisha ShoukathReplyJuly 4, 2012 at 5:16 am 

    @Syam, I have to agree with you on that 🙂

  4. Bob AllenReplyJuly 14, 2012 at 4:02 pm 

    When I saw a link to this article with it’s title I was very happy. At last, I thought, an article I can reference with solid numbers showing how Agile is far superior to traditional software development practices, a position I personally hold.

    CRASH! My hopes are dashed while I keep looking for any evidence of solid numbers. You make a few good points, miss some others, and provide zero foundation for any of it. I really wanted to like this article and would have happily referenced it liberally. I just cannot do that in good conscience.

    “There are scientific studies to prove that with data points…” but no references at all, no foundation.

  5. Nisha ShoukathReplyJuly 14, 2012 at 4:12 pm 

    Hey Bob, yes you are right, I should have given some reference here to the studies and numbers, here it is :
    See slides 9 to 15. I had taken most of the data from the book “Business Value of Agile” by Dr Sone and others..
    Had presented this case in few agile conferences as well.. thats probably why I did not mention again here 🙂
    Thanks for pointing it out. I will add the numbers’s part into the article.

    • Nisha ShoukathReplyJuly 14, 2012 at 4:32 pm 

      @Bob, there you go.. just added some research data into the post.

    • Bob AllenReplyJuly 14, 2012 at 6:27 pm 

      Thanks for the quick response. Not being familiar with the material, I hope you’ll forgive me if I take a bit to digest it. As I mentioned I’ve been eager to find such a resource, so thank you.

Leave a Reply

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

21  ⁄  3  =