Scrum and Fixed Price Contracts

fixed priced contracts don’t make a great deal of sense in a scrum world. this is really because traditional software development and agile software development are two different paradigms … and solutions that work in one paradigm often doesn’t make sense in another.

this difference is paradigm is best explained by one of my favorite jokes from many years ago …

q: how many surrealists does it take to change a lightbulb?
a: giraffe!

in an environment where clients are only given one shot at getting the product they want, it makes sense to define your requirements upfront, and to then manage any risk by putting a dollar limit on the cost.

agile teams are collaborative. and, they work the product backlog in the order specified by the product owner. if it makes sense to deliver high value functionality earlier they will do that. and, a good team will continue to incrementally deliver high value functionality on an ongoing basis.

the risk profile to the client is now substantially different because they’re getting regular increments of what they want in the order that they’ve specified. so, it’s reasonable to argue that a new type of contract would be more sensible for the new paradigm. and indeed there are different types of contract that work better than others [in an agile environment].

i’ll write more about agile contracts in the final part of this series and i’ll present a number of contracts that are more suitable for software than fixed priced contracts. for this post, i’d like to discuss our options if there were no alternative to a fixed price contact.

how to do agile with fixed price contacts?

beware fixed-price, fixed-scope contracts [2]. these are the most difficult to navigate simply because if we fix both the price and scope then the only remaining variable is software quality. scrum teams fix quality by having a robust (and invariant) definition of done . by fixing all three constraints; price, scope and quality we have a recipe for a death march [1] project.

an alternative to fixed-price, fixed-scope is to have a fixed-price, variable-scope contract. this works better because we can now fix product quality … but customers must now deal with variable scope .

this is not something they need be frighted of, rather it is a tremendous advantage to the customer. it does require changes in behavior; customers need to understand how to deliver value from prioritizing the backlog and, how to release early to drive revenue. both of these ideas require quite different concepts of software and value, and hence neither of these changes are easy.

variable-price , fixed-scope projects also work very well with agile projects. these often go by the name of time and materials, with a fixed scope . in a presentation at agile 2008, jeff sutherland presented a paper called “money for nothing and change for free” [3] in which he present two different strategies for fixed-price contracts which he called “money for nothing” and “change for free”. although there are some subtle differences, the strategies outlined by jeff are either fixed-price, variable-scope or variable-price, fixed-scope .

a better solution

fixed priced contracts are part of the culture of software in many companies. it’s simply the way in which things are done. part of the problem is that we have educated customers to expect fixed-price, fixed-scope by our past behavior. they have asked for fixed-price, fixed-scope and we have delivered exactly that [often at the expense of software quality]. the next time our customer want’s a product at a fixed cost they know who they can turn to.

to change the culture of fixed-price, fixed-scope contracts we need to change the culture of our industry; we need to push back and say that we value high quality products, and as a consequence we need to redefine our software contracts.

there is a risk in this approach. our customers may decide to walk away and offer the work to a competitor. this is a question we need to discuss, and decide if producing a high quality product is worth that risk. i think it is.

in the last part of this series on fixed priced contracts, i’ll present a variety of contracts which are often used with agile projects.

references

[1] http://en.wikipedia.org/wiki/death_march_(project_management)
[2] in this article fellow scrum trainer, jurgen, argues that fixed-price contracts are not only possible, but desirable. i feel that jurgen has totally missed the point here. sure, we can continue to do business the way that we always have done. i feel, however, if there is an opportunity to improve then we would be foolish not to take that opportunity.
[3] “ money for nothing and change for free ” by jeff sutherland.