Continuing our three part series about contracts and agile software development, here is part 2 about how to handle the fixed price environment that most of us work in today:

If you are an agile development organization, but you do actually have to submit a bid for a fixed price, fixed scope contract anyway, there is no way around adding an ugly up front requirements phase in front of your shiny agile process.

Doing this you can use the same estimating techniques here for an agile project as if you were doing a traditional project. E.g. check out Steve McConnel’s “Software Estimation, Demystifying the Black Art” for some good coverage of this.

But even if you are forced to add a traditional requirements phase (and thus waste a lot of money since on average you will be spending 64% of that time analyzing features of no value to the customer), you can still get significant benefits from using agile development:

• An agile team will have higher productivity than industry average. You will be able to complete the project in half the time and have a nice profit.
• An agile team is skilled in estimating since they work with estimates every day. They will also know their historic velocity. This gives you a better position to bid from.
• In a high risk situation you can select to do what a really big and successful telecom supplier does. Before bidding they run 3 iterations on each big new project, taking the cost themselves. After this they have a measure of the velocity of the teams involved and can make bid with high confidence.
• When you are awarded the contract, you can offer the customer to add an optional, risk free, agile clause to the contract. This clause is sometimes called “Money for nothing, change for free”. The clause will invite the customer to cooperate in an agile manner, making changes at no cost as they see fit as long as the total work is not changed. It will also allow the customer to stop the development whenever they want, paying a fee of 20% of remaining work as compensation for loss of opportunity. Usually 80% of the value of a system comes out of 20% of the features. So, when the customer has received 80% of the value, it can stop the development and not waste anymore time and money on developing low value features. The customer will pay 20% + a termination fee of 20%*80% = 36% of the initially agreed cost and will have the project delivered early. If the supplier was counting on a 15% profit for the time spent, it will instead get a 95% profit counting the termination fee also. And so the evil fixed price contract has been transformed into a win-win situation!

Once the customer has experienced the ease and power of being an agile customer, it is likely that they do not want to work in any other way again. Probably this means that there will be more business coming your way also. Also, the next time you work with a customer like this, there will be trust between the companies and you may not have to bother with the up front requirements waste and the fixed price contract.

In the next and final part in this series we will cover other types of contract that has been successfully used to encourage more productive cooperation between companies.

– Henrik

When presenting the agile approach to audiences new to the ideas, one comment is by far the most common. It is: “How can we do this, we have to work with fixed scope, fixed price contracts?”

We will cover this question in a three part newsletter, here is the first part “What’s wrong with fixed price contracts?”:

When practicing agile software development, the focus is on delivering customer value every month, sometimes even more often than that. Every iteration we do completely develop a few of the highest priority features. At the end of the iteration, ideally, the feature is finished and already deployed at the customer site. No work remains and the feature is actually done when we call it done. The customer knows exactly what the status is and may be able to start profiting from the partly finished system very early. The team benefits since it can forget about the previously developed features and move on at full speed to do new tasks. We also embrace change by allowing allow our customers to change priorities and add and remove requirements at any time as they wish. As long as we did not start working a feature already we allow this at no cost, no fuss. This is currently the most efficient and proven method to develop software known.

So, how does this relate to contracts? Traditional thinking is that by specifying and controlling scope you can protect yourself so that the other part will not take advantage of you. Trying to fix and control scope leads to some severe unexpected consequences though:

• Trying to limit scope, actually makes scope grow. Customers tend to put everything they can think of in their fixed scope requirements specifications. Then they put some more stuff in, just in case. They know that if they do not get every possible feature into the requirement specification, the supplier will try to squeeze out lots of money for changes later. Thus, on average 64% of the features in the requirements specification are things that will be seldom or never used. I.e. compared to a project focused on delivering value, trying to fix and control scope has more than doubled the project cost by wasting time on documenting and developing features of no value.
• Another thing that buyers try to do by using fixed price contracts is to transfer the risk to the seller. For this the buyer has to pay a premium. But who owns the risk really? If the project fails to deliver, the buyer usually is the one that will be in trouble anyway. So, in practice the buyer is always the one owning the risk. Even if there is a fixed price contract with penalties for delays etc, this is usually of little value if a system needed for the customers business is not delivered.
• Another aspect with fixed price contracts is that controlling scope and managing change takes a lot of resources. According to “Dyer, Collaborative Advantage, 91-96”, these types of costs dominate most vendor-supplier relationships.
• Fixed price contracts are often awarded to the lowest bidder. Bidders know this and make bids that barely break even. The profitability of the project is then saved by charging big sums for changes. On average, 35% of all requirements change during a project, so this is a safe strategy from the seller’s point of view. The problem with the strategy is that it fights change and puts strain on the buyer-seller relationship. Change is legitimate and there are numerous reasons why change will always be needed. Without change, optimal value will not be produced. Yet, fixed price contracts makes changes hard and thus it does not create the best possible customer value for the money invested. The reason behind this problem is that the contract type does not align the goals of the seller and buyer. Thus it creates a non-productive, inefficient, climate for cooperation between companies.

So, perhaps you agree by now that fixed price contracts are pretty useless tools if you care at all about getting giving your customers value for their money? Or perhaps you don’t care about value being delivered to your customers? In that case you better hope that all your competition feels the same. All it takes it that one of them starts delivering value, and then your offerings may not be that attractive anymore.

In the next part of this newsletter we will talk about how to turn fixed price contracts into something workable and mutually profitable by using agile development. So stay tuned, and maybe wasting time by arguing over contracts can soon be history…

– Henrik