How do agility and fixed price fit together?

The Agile values and Scrum principles must also be respected in the contract agreement between customer and supplier. One has to understand what Scrum as a framework already brings with it to regulate the cooperation and to ultimately decide which practices should be used for the specific case. To answer the question as fully as possible, I go into these 3 aspekts one after another.

(1) To the values and principles : As you have already pointed out in your question, the customer would like to gain more security. He believes to achieve this through a fixed price and a solid, functional scope, which is pretty obvious. Because in this case the risk is apparently on the side of the service provider. Apparently - because the risk arises not only from the technical complexity, but also from the complexity of the customers business model. To set a fixed, functional scope at the beginning is therefore not only utopian but also highly risky from the customer's point of view. Typically, I expect variance of 25 to 100% in the estimate for the functional scope before the implementation starts. The same order of magnitude is still to come for the technical implementation. After 1/3 of the project progress the estimation accuracy is perhaps between 10% and 50 % in both areas. Fixed price with a fixed functional scope gives us unfortunately no way to use this knowledge for the benefit of the customer and the supplier. But as a service provider you also want security. Therefore you would prefer time and material. But where is the motivation for the service provider to do the best and not to extend the project and to live off the fat of the land. Each of the traditional approaches is always to the detriment of one of the partners. In most cases one attempts to mitigate these shortcomings by other clauses in the contract. For example with the help of the rules for change requests. Such clauses often make customers feel as if they were taken to the cleaners. Or the service provider has the feeling of always having to deliver more as it was agreed. To put it briefly - it makes no fun and usually ends in tears. The Agile Manifesto proclaimed to a change in values : We value "customer collaboration over contract negotiation". So Agile demands from our customers to satisfy their need for security in other ways as through the usage of a fixed price contract. You will find the values to help thereby in the other two statements : * We value "Working software over comprehensive documentation " * We value "Responding to change over following a plan"

For a contract to be agile, it must reflect the values and be composed the way that both supplier and service provider take to equal the project risk. Only then both of them are motivated to make the project a success. I like to compare this with scales . If they are not balanced from the very beginning and if you have not taken precautions to ensure that the balance is preserved throughout the project by readjustment, the project will almost certainly be a disaster and with even greater certainty, the contractor and the customer will no longer work together after it.

(2) What does Scrum provide us with? Scrum utilizes the following principles to implement the Agile values: Inspect and adapt principle is visible to the customer primarily through Review, Retrospective, Sprint Backlog Refinement, Planning and the possibility of changing the Product Backlog during the project. Transparency for all parties involved - including the customer - for example, by early and regular deliveries, which give customers certainty about the progress and very soon create value. And of course, fundamental rules of the game in collaboration between the customer and service provider roles, named Product Owner and developer team in Scrum. These rules should be part of an agile contract. And not to be put at the end as a supplement of a service contract but at the beginning as the basics of it. Thus Scrum as a framework establishes deliberately only the cornerstones of cooperation. And that's good, because by the definition each project is a unique project. This also means that any contract between supplier and customer is unique.

(3) In practice, this may occur like that: A company (customer) wants to develop a new, innovative IT product and to appoint one or more suppliers. The issue of security is of course the key question . The fixed-price trap is – thank God - already known to our customer - thank God - through the experience with previous projects and now his core question is: How do we find the right supplier? Of course, first of all, through interviews, review of records and references. But is this enough to put the entire project budget in one basket? In our example the customer decides to appoint only for one sprint first. So to say a fixed-price sprint contract. Thus the customer gets to know the suppliers better and learns do define his own requirements in more detail. And the team of the supplier learns to estimate the technological complexity more quickly. In addition, in our example the supplier is experienced with Scrum and provides the customer with a team that has worked together for some time already. A significant risk factor is gone. Therefore now the risk of the customer is 1-3 sprints at most relative to a supposed total project expenditure of perhaps 9-18 sprints till the first release. The Supplier may at any time lose the contract. A resale of the team on a new project takes maybe 2-4 months. The risk of being left with the personnel costs relative to the total possible profit, which he can achieve with the project, is for the supplier similar to that of the customer. After 2-3 sprints , the estimation accuracy and understanding of the required amount of functionalities for a first release is so good that a scope or cost ceiling for all must, all should and 50 % of all could features can be defined for the release with a good understood definition of done (ie, the non-functional requirements). This will leave enough room in the should and could range to functionally mend and correct as the project progresses without expanding the overall effort. At the same time customer and suppliers have defined some incentives in the contract to not fully utilize the capped total expense, but to release faster, value optimized and with minimum possible extent. Such a model is known in the agile community as "Money for Nothing , Change for free".

In conclusion, we can say: Fixed price and Agile fit very well together. Fixed scope and Agile contradict each other.