When you want to introduce Scrum in a fixed price project, the majority of people you’re talking to about this idea will immediately say that it’s impossible to use Scrum in a fixed price project. Do they know that for sure? Did they ever try it? The answer to both questions is ‘NO’, no doubt about that. So why does everyone accepts that this combination is impossible?
Well, the answer is quite simple in fact. When people think about fixed price, they implicitly think about fixed budget, fixed time and fixed scope. And yes it’s true that a fixed scope and Scrum can’t go together. That’s quite obvious because one of the base principles of Scrum is that scope just can’t be fixed. That’s the idea behind the product backlog: at the beginning of a sprint, the team commits themselves to implement the most valuable stories at that moment before the end of the sprint. But the sequence of stories and even the content of the product backlog -except the stories the team is committed to-itself can change at any time.
But fixed time and fixed budget are absolutely no problem with Scrum. An argument I hear a lot is that you can’t set a deadline at the beginning of the project because you don’t know what will be delivered in the end. Because you don’t know what will be delivered in the end, you don’t know when it will be finished and you don’t know what will be the total cost of the product.
Well in my opninion, in a traditional waterfall project when people negotiate about what will be delivered, when and how much it will cost in the end, they also don’t know how long it will take and what it will cost. That’s why most sales people and project managers multiply the initial estimations with a factor 3. And even then, when the deadline is reached, still a lot of issues need to be fixed and the customer will have to pay a lot for that.
Another fact is that the customer can’t predict the future. It’s stupid to think that a person can know all features he wants in a year. Of course his mind will change! Of course he will change his mind when he tests the product! And that’s what most consultancy companies know. So they can make a lot of money by implementing change requests. So the fact that you can’t predict the price of a product on beforehand is just true. But there’s no difference between waterfall and Scrum projects…
The problem is that people want to use the same practices in the offering phase with Scrum as they are used to use with waterfall and that’s a wrong mindset. You can already create a general coarse grained product backlog at that time. Based on that backlog, a minimum set of functionalities can be defined and budget and deadline can be defined.
One can make use of the principles ‘money for nothing’ and ‘change for free’.
Change for free means that the customer can replace stories from the backlog with other stories with the same amount of storypoints at any time without any extra cost. This guarantees that in the end, a customer will get the product he wants and won’t pay more for it than initially estimated.
Money for nothing means that the customer can say that he has enough functionality delivered at any time he wants, even when not all functionalities from the initial set are delivered. The customer will have to pay a fee to the consultancy company but in the end the price per functionlity will be cheaper than what they agreed upon.
So to conclude: a better name for fixed price would be fixed budget. And fixed budget and even fixed time can go hand in hand with Scrum. The best Scrum contract model is called ‘Variable scope and cost ceiling’.