Can a fixed price be predicted in advance for software that is developed agilely? That sounds controversial, no question. While fixed price contracts offer an advantage for the customer at first glance, billing according to time and material is tempting from the service provider's point of view.
But with fixed-price contracts in the past, haven't you found that the budget was exceeded many times over in the end? Do you know by what percentage the budget for large IT projects is exceeded on average? Loud a study by Flyvbjerg and Budzier by 400%!
And how often have you experienced that after a waterfall project with many years of implementation time, the project clearly missed its goal when it was accepted? Why does this happen so often? With this type of project, the business value is fixed at the very beginning and is not corrected again during the course of the project. In contrast to this are agile projects: While a complex and detailed description of the scope of the project is part of the contract from the beginning of the classic fixed price contract, the agile fixed price starts with a complete but not detailed description of the requirements. This means that changes can be reacted to promptly at any time. In contrast to waterfall projects, agile projects also work in iterations (so-called sprints), at the end of which there is a fully tested and therefore ready-to-accept work package.
The model of the agile fixed price was developed so that the cooperation between service provider and customer has a contractual framework in agile projects. The focus is on balancing the interests of the customer and the service provider in terms of budget security and cost containment.
In the beginning there is the vision
At the beginning of a project, you as a customer have to ask yourself the question: What do I actually want? What should be achieved at the end of a project section (sprint)? For example, you want to set up an online shop that has various product filters, a shopping cart function and various payment functions. This vision is worked out in a workshop together with the customer and the service provider. All team members agree on this vision and have the same goal in mind. The complete framework of the project (scope) is the subject of the contract and is recorded in so-called epics. In contrast to a specification, the epics only roughly describe your requirements. The result of this workshop is the indicative fixed price framework, which is not yet binding.
Checkpoint phase: Time to get to know each other
Within an agile contract model, costs and deadlines are only fixed after an initial test phase (also known as the checkpoint phase). The scope remains variable in order to be able to react flexibly to new circumstances. The checkpoint phase usually lasts two to a maximum of five sprints and is negotiable. In this phase, the customer and the service provider can get to know one another and create mutual trust. Especially with new business relationships, it makes sense to extend this checkpoint phase to give each other time to get to know each other's ways of working. The checkpoint phase serves as a trial period for the cooperation, at the end of which there is already a deliverable partial product that already provides the customer with added value.
At the end of the checkpoint phase, the experiences gained from the first collaboration are compared with the original assumptions. In addition, after the checkpoint phase, the indicative fixed price range will be converted into a maximum price range. This gives the customer more planning security. If both parties to the contract agree, the conditions for further cooperation must be contractually fixed. ## Riskshare: How do we deal with risks? An important part of the contract is the big topic of “dealing with risks”. Because with the agile fixed price, nobody bears the risks alone. The risks are allocated to the customer and the service provider according to a key defined by both sides. With the agile fixed price model, it is crucial that the customer buys sprints that lead to a functional partial product that can already be used. The focus is always on the question: Is this user story essential for us as a customer? Does the user story really provide functional added value or is it pure luxury or even pointless?
In the case of agile fixed prices, the motto “a problem shared is a problem halved” applies: Riskshare is a self-insurance method for all parties involved in a project in order to fairly distribute the negative effects of unforeseeable events to all stakeholders in contractually agreed proportions. At the same time, Riskshare is also a sign of solidarity, which shows: "Yes, I am ready and will take my part of the responsibility and do everything to ensure the success of the project." The resulting responsibility of everyone increases the solidarity with the project .
Cost-neutral changes: Exchange for free
With the agile fixed price, subsequent changes to the project scope are possible at no cost. One speaks here of “Exchange for free”. It should be noted that the customer defines new requirements before a sprint and exchanges them for requirements of the same scope. If an additional request is desired, it is an additional effort (change request) that is not included in the agreed maximum price. ### Open communication, same language and decision-making authority
In order to avoid misunderstandings, customer and service provider must speak the same language and have the same understanding of the agile fixed price and the underlying agile methods. A workshop before the start of the project is absolutely necessary in order to clarify all content-related and technical questions and to define expectations together.
In the subsequent cooperation phase, concrete feedback must be obtained again and again: Has the story been implemented correctly? What is still missing? Why were the expectations different? While the developers learn that the stories have to be implemented within budget, the customer learns that they are continuously involved in the development process and have to make important decisions again and again so that the project can be successfully completed in the end. It is therefore strongly recommended to contractually regulate who informs whom and when and which persons are authorized to make decisions. If the product owner is not authorized to make decisions, this can have far-reaching consequences: In the worst case, the sprint can be aborted.
Is this something for us?
And for whom is the model of the agile fixed price suitable? Of course, there is no general answer to that. It is clear that the agile fixed price is best suited for larger IT projects, the scope of which cannot be specifically limited and some of the requirements are still vague in the future. For small standard issues that follow the same pattern, the model is certainly exaggerated. However, the agile fixed price stands and falls above all through the common understanding of the vision and getting involved in the agile process. However, if the decision for the agile fixed price is made consciously, it convinces with its flexibility, constant transparency and minimized cost risk.
We recommend the book to anyone who wants to delve deeper into the topic of "agile fixed prices". "The agile fixed price" by Andreas Opelt, Boris Gloger, Wolfgang Pfarl and Ralf Mittermayr, which one here also served as a source