Scrum and Fixed Price contracts

"Should we offer to do this project Scrum or fixed price?". That's a question I've actually heard when discussing a bid on a new project.

That question is wrong in many ways.

Fixed price is a type of contract. When people say fixed price they often mean fixed price and fixed scope.

Scrum is a framework for developing complex products. It's not a contract type. The Scrum Guide does not even mention contract types.

Comparing Scrum with fixed price is like comparing the genre of a book with the word processor it was written with. "Is this a thriller or an Adobe PageMaker book?".

See? That makes no sense at all.

There's a risk for the vendor in fixing both price and scope at the start of a project. Most software development projects are exploratory in nature. There are many unknown variables at the start of a project. If the vendor was off with their estimate they might lose money on it.

There's a risk in fixing the scope for the client too, although they often don't realise it. They might get exactly what they asked for, but discover, as the project progresses, what they asked for is not what they actually needed!

Scrum and fixed-price-fixed-scope contracts are often seen as opposing entities. The power of the Inspect & Adapt cycle of Scrum is weakened when the scope of the project is fixed. You could still inspect the product increment at the end of every Sprint during the Sprint Review, but how do you adapt to new insights when you can't change the scope?



The vendor could allow the client to swap obsolete product backlog items for new product backlog items that are similar in size. That's great for the client, but it doesn't do anything to mitigate the risk on the vendor side. If the vendor underestimated the project, they still have to do the same amount of work.

No matter the chosen project management methodology or product development framework, be it PRINCE2 or Scrum or whatever, a fixed-price-fixed-scope contract will be a cause of headaches in the context of software development. The quality of the resulting product may suffer, leaving all parties unhappy.

Are there contract types that work better when developing software? I'll talk about that in a next post. Meanwhile, I'd love to hear about your experiences with Scrum and working Agile in a fixed-price-fixed-scope situation.