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.

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.