Fixed price is not a contract for work
First of all: a fixed price and a contract for work are two different things. We can agree on a fixed price (a budget box, so to speak), but leave the content open. Or vice versa. Or both.
Can a fixed price be agile?
When Scrum works properly, we optimize value over time (budget). A Scrum team delivers an executable increment every sprint. If we have a given budget, there is at least one executable product at the end of the budget. If the value has also been optimized correctly, it is the best that could have been delivered at the time and within the budget.
It doesn't get any better than that.
With fixed-price endings, the client (product owner) can decide whether he wants more product features and therefore invests more budget (sprints), or whether the product scope is sufficient. In contrast to traditional approaches, however, there is always something that can be used.
Conclusion: a fixed price can certainly be agile.
And if nothing comes out?
We limit the risk of the supplier not delivering to one sprint if we take the potentially deliverable increment and the sprint review seriously. Then you quickly realize whether the project is moving forward or not. The probability of non-delivery after several successful sprints is very, very unlikely. Of course, this assumes that the team delivers an executable increment every sprint and that the client also looks at this. (Incidentally, this is often the problem with pseudo-agile projects).
What if we finish early?
In the event that a product is finished before the budget box, there is an agreement that the client and team split the remaining budget 50/50. In the agile world, this is often referred to as "Money for Nothing". "Money for Nothing" avoids wasting the budget when there is nothing more to do, and it shares the risk fairly between both parties.
And what about a contract for work?
What if we want a contract for work in addition to the fixed price?
Then it is relatively easy per sprint: the sprint goal is a small work contract anyway. It defines the goal of the sprint and still allows for variance in the implementation of the product backlog entries.
The work contract is similar for the overall product: an "epic" or a product vision ensures that the product is heading in the right direction and at the same time leaves room for changes in this direction ("Change for Free“).
However, the client should not shoot themselves in the foot by concluding a contract for work that includes a detailed product backlog. Then the whole advantage of the agile approach (the "change for free") is gone.
Write a comment