Agile vs. Waterfall Development Cost Models

By Pete G. Operations

You have a budget. You need an app. You have to get an app for that budget. What’s the best way to make sure you get an app for your budget? Fix the cost, fix the scope, right? Wrong!

In a waterfall fixed cost, fixed scope project you don’t get deliverables till the test phase at the end of the project. But you already know that it’s when you finally get your hands on your product that you really start to learn about what it does and more importantly what you need it to do. That’s when you learn if your carefully specified requirements you spent such a long time working on are actually any good! Have they been followed and understood? Even if they have, markets change and you will certainly have a clearer understanding of what you need from your product.That’s when the Change Control Process kicks in.

There is a barrier built in to waterfall projects to actively prevent changes you want to the scope of your own product. The change control process. This little clause you might not have read in the contract effectively switches the nice traditional fixed cost, fixed scope project you thought you wanted into a variable scope, time and materials contract.

This means that when your boss is breathing down your neck because your mobile app development deadline is fast approaching and you just found out you don’t have what you need in your product you have to negotiate about every change with the contractor to get anything done. Nightmare!

So what’s the alternative? The alternative is not to give up control of the scope by using a fixed requirements document and don’t give up control our your costs by setting a fixed end date. Instead keep the control close and manage it responsibly throughout the project. It is your project after all!

In an agile project, we expect the customer to change their mind. We keep a living document of the requirements and use a backlog of stories to keep it alive. The backlog is the living document defining all the scope you might want to implement. Each requirement is specified as a story and comes with a estimate, a business priority and an agreed way to confirm when it’s completed.

An agile team regularly report how many estimate units they can do over a fixed time period and they call that number the team velocity. By counting up the estimate units in the backlog and dividing by the velocity you get the number of fixed time blocks needed to do all or just some of the backlog. Really simple!

Here are some of the ways that being able to empirically calculate your progress and end date can work for you:

  • Protect your release date – If you’re release date is slipping you can cut low value features to make sure you hit it and limit cost and time overruns. You can see this months before the actual date. Speeding up? Add the stores, or others, back to the backlog.
  • Protect your spend – With a fixed number of people on the team, time is effectively the cost. You can calculate the eventual cost of your project and make good decisions based on it to dynamically protect your spend.
  • Get the best outcome you possibly can – If you have a fantastic idea you want in the project the backlog lets you substitute your new idea for something valuable with the same number of estimate units. You can of course choose not to remove anything and simply calculate how much longer the team have to work to produce that new feature. This is the essence of agile change control.
  • Really see where you are in a project – Instead of guessing the percentage you are “complete” through the project, calculate it based on empirical evidence of the team’s real world and up to date performance.

Next time you embark on a project just think about this. Do you really want to hand over your control of your project before you even start?


Share this article

Subscribe to Our Thoughts