Using fixed price contracts for agile projects is not just putting lipstick on a pig
At the end of 2018, I was right in the middle of an ambitious project to replace a mission control system. My team wanted to let the dispatchers (i.e. our users) decide how their system should look like, were the first to use our new datacenter and, on top of that, had a lot of other mission-critical systems to integrate on the go. And those were just a few of the reasons why we decided to use Scrum for this project.
Having scored our first crucial wins, we were confronted with the bad news that our main system to integrate, the communications platform, would need to be replaced by a new system to be developed from scratch. We tried to use this situation to our advantage and thought this to be a great use case for yet another Scrum project. Unfortunately, we were rebuffed by the supplier for the system.
The supplier, who is one of our most esteemed partners for "classic" communication projects, did not want to follow an agile methodology. Their line of argumentation was that their experience with working agile is to face scope creep and therefore miss deadlines and have cost overruns. Being held responsible for the timely conclusion of the project within budget limits as per a fixed price contract, they would have beared the brunt of the risk.
Can your team hold your supplier responsible for project success while working in an agile setting? Yes, I think you can, but you need to lend your supplier a hand. In the following, I will outline some approaches that ensure that your agile fixed price contracts are not just you putting lipstick on a pig.
What is the Purpose of Fixed Priced Contracts?
In fixed price contracts, the dimensions time and budget are fixed, whereas the quality dimension has a bit of wiggle room. Its main objective is to shift the majority of a project's risk to the supplier, who needs to commit to at least two of the three dimensions of the project management triangle.
This requires a project's scope and all of its requirements to be already precisely known at the beginning of the project, which is rarely the case in a VUCA world. Even more so, since requirements are often phrased in natural language, they can be interpreted in various ways. This often leads to a veritable blame game between the supplier and the customer when it becomes clear that the, seemingly, precisely defined scope and implementation is, indeed, blurry.
Creating Some Wiggle Room
Thus, rather than denying the reality of changes in scope and requirements after the beginning of a project, we want to embrace and even, if possible, use them to our advantage.
Let us start with creating wiggle room in your requirements: instead of trying to precisely state them, rather lay out a problem space within which a probable solution may lie. This gives your team the chance to incorporate user feedback during the project and your supplier the opportunity to come up with the best solution for your problem. A good approach for doing so is to initially elaborate so-called Epics to define your problem space, which are translated to more fine-grained User Stories in the course of the project. You can read more about Epics and User Stories in this blog post.
Creating wiggle room in the project's scope is a bit harder. In any case, you should try to avoid gradually expanding your project's scope when aiming for a fixed roll-out date and/or when your team has a fixed budget ceiling. A better approach is to define a minimum viable product (MVP) at the beginning of the project. You need to picture it as follows: the MVP is the first version of your product that covers all the Epics that enables your stakeholders to use the product in a satisfactory manner. Using the Kano model as reference, your MVP should cover all the basic needs of your stakeholders and only the most important performance needs or delighters.
Whenever a scope changes occurs, ask yourself the following: is it an extension of your MVP, a change of your MVP or a change within your MVP? I will dedicate a future blog post to how you can best handle all of those cases. Obviously, the MVP should be shaped such that only the latter case may occur frequently. Since those changes lie within your Epics' wiggle room, your team can easily address them by refining the respective User Stories.
Experiments Are Key
Besides the definition of a problem space, there exists one more important concept that you need to take into account in your agile fixed price contract.
Iterative development and agility is all about making repeated experiments to address complex problems. However, your complex problem does not only comprise your application, but also the way in which your team interacts with your supplier and your stakeholders. In Scrum, this interaction is inspected and adapted during the Retrospective in each Sprint.
In most cases, you already invested quite some time into comparing your various potential suppliers. You might have even conducted an agile supplier evaluation. Nevertheless, your team and your chosen supplier are about to take a leap of faith.
It therefore pays off to allow both your team and your supplier to reassess the situation after an initial learning phase, which can range from 3 to 5 iterations (depending on their length). The software developed during this learning phase should already be considered as part of the MVP and should therefore contain User Stories from its most important Epics. During a common meeting, your team, your supplier and your stakeholders will have a chance to both reflect the current state of the deveoped software and their interaction. At this "checkpoint", your supplier should also have the chance to correct any assumptions made about the development cost or time of the MVP.
A Simple Agile Fixed Price Contract
To make your current fixed price contract an agile fixed price contract, you need to
specify the work to be completed as an MVP that consists of the relevant Epics in your Product Backlog
define the roles, artefacts, meetings and iterations used in your agile methodology
only define one milestone: the roll-out date for your MVP
tie payments not to milestones, but to the subspace of your problem space that has been done (e.g. Epics 1 through 5)
define a learning phase of 3 - 5 iterations, at the end of which your team can signal whether to continue development of the MVP or not and your supplier can adapt any assumptions made at the beginning
In our "Bite" section you can find a simple infographic that succinctly summarises the above:
Care to Know More?
In case you live in Switzerland or the greater Zurich area, I can only recommend to visit Zurich Wilderness Park, where I shot the above photo of this curious wild boar. Although I am sure that it can be gentle at times, I would rather not try to put lipstick on it.
Trying to combine the risk-reducing mechanisms of fixed price contracts with the benefits of having wiggle room in the requirements and scope of your MVP is not merely putting lipstick on a pig.
It is rather a common agreement between your team, your suppliers and your stakeholders to focus on the essential of the product (the MVP), while still learning and adapting during its development. Above all, this requires everyone involved to play fair. For instance, you have to learn to take your supplier's side when your stakeholders are trying to extend the scope of the MVP. Learn more about how to choose the right supplier for this approach in this post.
Would you also like to know more about this post's topic? If so, then please post your questions in the comments below and I will be answering them. If the subject of your question is a hot topic, then I will dedicate a post to it in the future.