In my previous fixed price article I looked at why fixed price is not only bad for suppliers but also for clients. I also argued that contrary to popular belief using big design up front methodologies will not solve these problems. Fixed price is difficult no matter what methodology you use. In this article I want to look at why fixed price is still popular with many clients. Then we'll look at what we need to do to be a bit more successful at fixed price and how agile methodologies can help us do this.
To look at why fixed price is popular with clients I'll start with a comment I got on my previous article. Sergey Pyatigorsckiy commented "As to my mind, pure fixed priced project can be defined as a project nobody cares about. At best it's spending money, at worst - wasting money. That is why real huge governmental projects are fixed priced: Nobody really cares."
I tend to agree to some extent. Clients often don't care about the project, they often just want the software and be done with it and for them the easiest way to get this is fixed price. So fixed price projects and clients that don't care seem to go together. In most cases clients do care about the outcome of the project. Clients have a problem they want to see solved. Or, more cynical, in larger organizations, clients want a big successful project to show their manager. Often clients don't realize that in order to improve chances of a successful outcome they should care about the project. Most clients have experience with processes like buying a new car, they specify what they want, recieve a time and cost estimate, wait a few days and get their car. Why should software be any different?
Clients often don't trust the supplier enough to move away from fixed price to other contract types. Fixed price often seems a lot safer to a client because it allows them to push risk to the supplier. In practice this just isn't the case. The fact that a client can sue a supplier for breach of contract will not change the fact that the client doesn't get any software. Allowing the client to point fingers won't solve their business problem.
What do we need to improve our chances in fixed price?
Unfortunately we can't get rid of fixed price. But there are several things we can do to make the best of this situation.
- We need to make the best estimates possible within the limited time we have available before the start of the project with the limited requirements we have at that time.
- In order to reduce risk we need to keep a close eye on progress in order to detect problems as soon as possible.
- We need to build trust with the customer. Without trust there's no way we can break the fixed price habit in the future.
- We need to create a situation where we can break out the fixed price contract whenever requirements change without having to throw away lots of work in progress.
Agile fixed price
Fixed price projects will cause an agile team to make several compromises, up front estimation is not something we're used to doing, committing to those estimates even less so. Limiting scope is also not a very agile thing to do. But even within these constraints I do think agile has a lot to bring to the table in fixed price projects. Lets look at how agile practices will help us achieve the four goals I stated earlier.
Agile estimation
The hard part of fixed price is up-front estimation. You need time and a detailed set of requirements to create really accurate estimates. We don't have either so we have to make the best estimates possible with the least amount of resources. One of the best methods to do this is agile estimation. Even with the rough requirements you have before the start of a project it should be possible to create a set of user stories and attach rough relative estimates to them using something like story points. These can be transformed into a set of estimations using past velocity of the team. Keep in mind that it's probably a good idea to pad these estimates with a risk-factor. In my experience abusing agile estimation techniques like this will not bring you the most reliable estimates, estimates are never as unreliable as at the start of a project, but considering the circumstances it's the best option. Techniques that claim to be more reliable like function points analysis simply take too much time.
Agile risk management
Finishing stories every iteration is the best way to measure progress. A story is never 80% done. It's 0% done or it's 100% done. Everything in between is uncertain and will not allow you to measure progress. Agile forces you to finish stories every iteration giving you a clear picture of progress so you'll know early on when a project is behind schedule. This kind of risk management is very important in fixed price projects where missing a deadline can mean the difference between a happy customer and a lawsuit.
Build trust by showing working software
Actually finishing stories in every iteration also gives you the ability to show working software every time. In fixed price projects this does not seem very important. Clients don't expect to see software until the very end, and on the many non-agile fixed price projects I've been on that was exactly what we were aiming for. But when you want to build a relation based on trust with a client this is not the way to go. The best way to show a client that they can trust you is to be able to show them what you're doing. Show them working software.
Break out of the contract
Showing your customer working software has an interesting side effect. They'll want to change requirements. But because of the fixed scope this won't be possible without breaking out of the contract or by doing work outside of the contract, giving the customer features for free.
There are two things that make breaking out of a fixed price contract hard. First of all the supplier will want to bill the customer for the work that has already been done. But if you have lots of work in progress defining progress is hard, fortunately in an agile project progress is much easier to measure as we've already seen. Also clients will probably not want to pay for software when many important features are missing. Prioritizing work according to client business-value will make sure the most important features will be implemented first. It will be much easier to switch from fixed price to a more flexible contract type halfway through a project.
In situations where you can't get around working with fixed price contracts people often give up on doing things agile altogether. To me this is a bit like someone who is trying to stop smoking who, in a moment of weakness, smokes a cigarette, gives up completely and starts smoking one pack a day again. The fact that fixed price makes you abandon a couple of agile practices does not mean you should give up on agile altogether. I hope to have shown some compelling arguments for doing fixed price agile in this article.