Agile vs. Traditional Development Cost Models …Maybe

One of the developers in the lab had been talking to his friends, who is being introduced to Scrum.  One of the value proposition that they are selling to his friends company is that Agile will save you money in project cost.  I want to caution Agile Practitioners on selling this concept.  Agile produces higher value for the money but doesn’t necessarily save you money in project cost.

The models below are based on the following assumptions.

“Given that you have one project that is fixed 12 months in duration and has a fixed amount of resources. What is the overall cost of the project?”

It is important to note that we are not talking about maintenance cycles just the cost to the product owner for a project.

  • The project will last 12 months from January to December
    • Resources
      • 2 Business Analyst – Project cost of $40 an hour
      • 2 Systems Analyst – Project cost of $40 an hour
      • 4 Developers – Project cost of $70 an hour
      • 3 Quality Technicians – Project cost of $45 an hour

Here is graph depicting the resource cost of a traditional model over the course of a year.


Not surprising this is what a traditional cost model looks like for a waterfall project but I wanted to add another dimension based on a value stream vs technical debt.


You can easily see how the cost of change is higher towards the end of the project due to incurring technical debt.  In a traditional methodology technical dept is not addressed head on, it is merely prioritized in a defect log.  I think all of us at one point in our careers have launched a product into production with a couple of hundred known defects.

Technical debt is the unfinished work the product development team accumulated from previous releases. This debt includes: design debt, where the design is insufficiently robust in some areas; development debt, where pieces of the code are missing; and testing debt, where tests were not developed or run against the code…”

Kane Mar has an excellent article on the subject as well.

Look at this from a Business perspective.  Does it matter that I have this debt?  The project is done and I am making money.  Who cares if it doesn’t work exactly as I want. The point of the matter is, it is making money.  Money that can pay for the maintenance line.  Think Microsoft Vista.  Was it perfect?  NO!  Was it close to being perfect?  NO!  Did MS know that Vista had lots of bugs? Yes! Was it done to a state that could bring in money for the company?  Yes!

One other very important attribute is that the “Value Stream” of the project is not incurred until the end of the project.

Value Stream is the ROI that is incurred when components of a project are introduced into a production environment producing a revenue stream for the company.

Now come the Agile models.  This first set of graphs is based on a evolving Agile team that practices an iterative development methodology  but only introduces code into production at the completion of a project.


As you can see the cost of requirements, development and testing are fixed.  This is due in part to the time boxing effect of Agile’s Planning, Development and Testing into smaller releases throughout the duration of the project.  To some this may seem to be a horribly ineffective use of resources but for me it makes things more predictable.  You will also notice that their isn’t a design cost.  Theoretically their is it is just absorbed within the development and planning stages.

Lets look at the overall cost of this type of Agile Development.


As you can see the project cost are almost doubled in comparison to the traditional model.  However the value stream is substantially more, due in part to the constant feedback from the product owner and the embracement of change principles.  The technical debt is a fraction of the traditional model due in part to quality being introduced from the onset through the development team TDD practices and the testing teams automated testing.

But lets look at a mature Agile Team that introduces working code into production at the end of every release!


The value stream is substantially higher due in part to introducing working code into production early on in the project, about every other month!


So lets break it down.

Methodology Project Cost Value Stream Technical Debt
Traditional $354,600 $300,000 -$161,000
Agile Evolving $650,400 $500,000 -$8,600
Agile Matured $650,400 $1,550,000 -$8,600


If your product owner is strictly concerned on cost and that is all that guides their decision making, then stick with a traditional model. (By the way you may want to consider looking for a new job if you work for this company.)

As you can see Agile provides tremendous value and not necessarily project cost savings.  The quicker you are able to stabilize a production release the more you will increase the value stream for the business.  A win win for everyone involved.

If you noticed I intentionally left bold the phrase “project cost savings” because as we all know, projects have end date but production applications don’t!  Production systems need to be maintained and in a traditional model this is where the cost incursion becomes enormous due to technical debt.


Before I get a borage of comments on the data that supports these claims, the data is based on perfect scenarios in both methodologies.  Like all data it can be adjusted to many outcomes I just wanted to be as fair as possible to both.


I am really curious to see what this is going to spark out there.  Looking forward to your comments.

kick it on

About Joe Ocampo

My personal philosophy is simple: "Have a good strategy that sets the environment for success through the enablement of the whole. Be agile but with a mind towards pragmatism. Delegate to the best qualified individuals, but don’t be afraid to involve yourself in all parts of a job. Treat everyone with respect, humility, and with a genuine pursuit towards excellence." Respected business and technical leader with expertise in directing organization towards effective results driven outcomes. Proven ability to perform and communicate from both technical and business perspectives. Strong technical and business acumen developed through experience, education and training. Provides the ability to utilize technology, harness business intelligence and execute strategically by optimizing systems, tools and process. Passionate about building people, companies and software by containing cost, maximizing operational throughput and capitalize on revenue. Looks to leverage the strengths of individuals and grow the organization to their maximum potential by harnessing the power of their collective whole and deliver results. Co-Founder of
This entry was posted in Agile Project Coaching & Management, Agile Teams. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

19 Responses to Agile vs. Traditional Development Cost Models …Maybe

  1. Interesting. However all you are really talking about here is what sits in the middle of the “iron triangle” (

    Agile normally places quality as the inviolate centre of the triangle leaving cost, time and scope as the variables.

    Waterfall typically puts time in the centre, leaving scope, cost and quality as adjustable.

    In your example you are fixing both time and cost (limiting the resources) so if functionality is the requirement then the thing that will give will be the quality. And because all 3 other factors are fixed then quality will suffer a lot more than what your example might indicate.

    As for Vista, MS let time, cost (and quality) slip because, for them, functionality was the core of their triangle.

    So the argument is not agile vs waterfall, but what is the right “centre” for your iron triangle? Well, that all depends on your business and like all things in I.T. the answer is “it depends” :-)

    Nice post, by the way

  2. Joe Ocampo says:


    I couldn’t agree with you more about quality, Agile and the “Iron Triangle”.

    This particular example we derived from an argument that questioned, that business does not care about value, they care about cost. I rebutted with emphasizing quality but decided to humor the individual with the fixed time and cost models.

    You observation about “quality will suffer more than my model shows” is interesting because my original model was through the roof on technical debt for the traditional model but I figured people would never believe outliers of that magnitude so I brought it in.

    I am officially changing my blog title to “it depends” :-)

  3. @Joe

    Through the roof technical debt being about 10 times what you’re showing, or worse?

    I’ve seen technical debt where the bugs per LOC ratio was almost 1:1. So bad that the only bugs tracked were those that actually crashed the system. Everything else was ignored (even calculations that were blatantly wrong).

    But, hey – they shipped on time :-) Even if the project fell under the “death march” category.

    P.S. LOL on the title change!

  4. Niklas Mehner says:

    For those interested: I found “Software by numbers” ( a quite interesting book on this topic.

  5. Joe Ocampo says:


    It was about 6 times worse that what I showed BUT this was a perfect world example and change control was kept to a minimum. Introduce change controls and I can easily see it approaching 10 times or greater.

    >technical debt where the bugs per LOC ratio was almost 1:1

    One word, WOW! The funny thing is everyone is OK with it. They acknowledge the fact that there are holes but said launch anyway. I know this goes back what do they value most. But geesh…. Imagine if a plane had that ratio!

  6. Joe Ocampo says:


    Good find I will have to take a look at it.

  7. GS says:

    I am just curious. Why do you say that Agile project would have higher cost? Isn’t cost primarily a function of effort required to produce the code? Are you saying that Agile would have resources spending more effort? Or is cost increasing because in agile all the resources are “on” all the time leading to resource management which is not optimum form cost reasons?

  8. Joe Ocampo says:

    >Isn’t cost primarily a function of effort required to produce >the code? Are you saying that Agile would have resources >spending more effort?

    It is not that there is more effort from any one resource group it is the fact that ALL resource groups are utilized throughout the entire project. Developement, which is the highest cost, will be incured immediatly as opposed to traditional models where the development cost isn’t incured until the middle of the project timeline. This is the case for all project stakeholders. The important aspect of all this is that Agile does not focus on project cost but the value stream that is produced thus decreasing the overall maintenance cost, which is where most orgnizations are taxed.

  9. Interesting post and comments!

  10. Jleer says:

    Hey Joe,
    You forgot something. Where’s the technical writer?????? This person is crucial to the deployment of whatever is developed.

    Jon Leer
    Leer Technical Communications

  11. Dwasco says:

    Can you please fix all the broken images in the article so that it makes more sense?  Thanks!

  12. N Horton says:

    Joe, can you fix the links for the images in this post ”
    Agile vs. Traditional Development Cost Models …Maybe”  The article is interesting and I would like to view the links to take a look at the graphs also

  13. N Horton says:

     Joe, I would like to reference this post in a paper that I am writing for my Master’s class in CIS.  How may I obtain the high-res images of the graphs you have used to here?