Risks and Rewards of Agile Development

While fixed price contracts can be used with agile projects, flexible contracts fit more naturally with the agile approach.

But, under a flexible contract, how can we ensure that neither party is exposed to excessive risks? This page describes one solution. It is a very common solution, which I call "Cancel-After-Any-Phase". First, let's consider the traditional alternative...

The Traditional Fixed-Price Approach

In the traditional approach, scope is fixed up front. If you are a customer, then time and cost are also "fixed" from your persepective. OK, you know that things might take longer than planned, so the delivery date might slip. But, thanks to the fixed-price contract, the supplier will absorb the extra cost.

There are two well-known drawbacks:

Firstly, if things do take longer than planned, something's got to give. With scope, cost and time all fixed, quality is the only remaining variable.

With scope fixed, you have to pay extra if you change your mind. You raise a change request, then the supplier quotes a price which they feel will be profitable. Too often, the temptation is to quote high to "make up" what's been lost on the main project.

The prevalence of change requests indicates that fixed price contracts don't actually guarantee you'll get what you need. They really guarantee you'll get what you think you need, at the start of the project.

There is also a lesser-known drawback to fixing scope, and it's very important:

Attempts to control scope often increase it. This is decribed very well in the book Lean Software Development. I've noticed this tendency myself, and I believe it happens because because even low-priority features are included in the up-front design, since no-one wants to fix the scope too low. With a more flexible contract, its easier to focus everybody on the things that really matter.

The Agile Approach

Agile software development proceeds in a series of short stages, called iterations. Working software is released at the end of each iteration. At the start of each iteration, duration and effort can be fixed for that iteration. The functionality varies. If the work turns out to be too much for the current iteration some features are postponed until the next.

(This is a slight over simplification. In some agile processes, the software is not released at the end of every iteration. So, if you run an agile project in the manner suggested on this page, you should insist on actual delivery of software at regular intervals - say once every 6 weeks.)

Managing Risk

So, how do you know how many iterations you will need? What if features keep slipping until you need far more iterations that you originally expected?

There are several good solutions. I'm going to describe the one that is probably most common in the agile community. I call it "Cancel-After-Any-Phase".

It works like this: Iterations are short, typically one month long. At the end of each iteration you receive working, tested software. So:

You get excellent visibility into the process. You can see the progress that the team is (or is not) making. Instead of seeing progress displayed in Gantt charts and status reports, you see actual released software, running at your own premises.

You can cancel at any time. You can cancel the project at the end of any iteration. You still have the working, usable software from all the iterations completed so far.

For these reasons, you should never be faced with a situation where you say, "This was only supposed to take 6 months, but its taken 12 so far and it's still not finished." Just don't let it get to that point. Cancel the project after 3 months if you're not satisfied with the rate of progress.

What's Fixed?

Is anything fixed under this approach? Time, cost and scope are not, so what is? The answer: Quality and value for money.

Agile methodologies aim to hold quality high, no matter what. To maintain quality agile processes use rapid feedback, simplicity as a design goal and, in many methodologies, rigorous automated testing.

More importantly, agile methodologies seek to maintain high value for money. I remember a manager who purchased fixed-price software, saying, "When we buy a system, only about 10% of it is really used." Agile methodologies help you buy more of the stuff you need, and less of the stuff you don't.

They do this by:

Establishing a cooperative culture, where supplier and customer work together to maximise the "bang for buck".

Giving the customer the freedom change their mind, with minimal bureaucracy and expense.

Delivering the most important features first. After the most important features are completed, the remaining iterations deliver less and less value for money. (They still cost the same, but they deliver less business value since you've already done the most important bits.) So the customer can just call a halt, stopping the project when the "bang for buck" drops. The customer only buys work that delivers good value for money.

Summary

Cancel-After-Any-Phase creates a win-win scenario because:

The customer gives up some certainty about scope and cost. In return, they get quality, value for money and visible progress.

The supplier gives up some certainty about the duration of the project. (If they don't perform, the project could be canceled very early.) In return, they are assured of fair payment for good work.

Both parties benefit from the open collaboration fostered by agile processes.

Finally, I re-iterate that while Cancel-After-Any-Phase is the most widely-publicised structure for agile projects, other solutions are possible too. They include two-phase contracts and target cost contracts, which give greater certainty about scope.

Page History: Created 29 April 04. Last updated 22 Feb 07