While digital has become of the essence, not all organisations have sufficient internal resources to develop their solutions in a limited time. In this case, management must count on service providers capable of delivering the expected turnkey value to intervene. They are then faced with the same problem: how do you manage risks while benefiting from an agile approach? Let’s take stock of the agile fixed price, a hybrid contracting method that reconciles commitment with results, respect for deadlines and flexibility.
1. What is the agile fixed price?
The agile fixed price has been developed over more than ten years to avoid the disadvantages of traditional contract agreement methods. This formula combines the best of both worlds.
Fixed price and agility, two contradictory notions
The fixed price is presented as a contract agreement method in which all the elements are “locked”.
- The specifications set the functional scope: the extent of the functionalities to be delivered.
- The contract sets a deadline for achieving the expected result.
- The cost is fixed and defined in advance.
While this model may seem reassuring, the fixed price is not suitable for agile project management, in which the notion of guaranteed results does not exist. Agile teams, whatever the methodology used (Scrum, Squads, etc.), do not commit to achieving a perfectly defined result at the end of the allotted time but simply to deliver several functionalities (in other words, a specific product quantity) in each sprint.
The mode of operation is, therefore, radically opposite. Where there is a fixed price, the service provider is under financial pressure and generally resorts to the so-called V-cycle methodology, a linear management method that does not support change well. In pure agility, the service provider iterates over short cycles (sprints) and can adapt to change (changing user needs, for example).
The agile fixed price, a solution born out of slippages
Before the development of the agile fixed price, traditional contracting methods generated a number of drawbacks. On the one hand, management, based on time-based billing, worried organisations due to the lack of visibility on the final cost.
On the other hand, the pure fixed price has demonstrated its limits. Indeed, in this model, the sponsor and the service provider do not create real relationships, which often leads to difficulties with drafting and interpreting the specifications. Results? When it comes to platform, application or website development, the fixed price contract sometimes leads to disaster:
- exhaustion of the service provider’s teams, who must undertake significant work initially to deal with functional “gaps” and specification management;
- monitoring difficulties for internal teams;
- drift in terms of deadlines, which carries a significant risk of having a product that does not or no longer meets market expectations or incurs an additional hidden cost.
The agile fixed price was born from these observations and responds to a completely different philosophy.
The agile contract is based on trust
Unlike the traditional fixed price, the agile fixed price is not based on a specific outcome commitment but on a commitment to collaborate and do your best to maximise value. So it is built on the notion of trust, which is a key value of agility.
Unsurprisingly, this philosophy impacts the working relationship. For the organisation, it is no longer a question of delegating the project but rather of co-constructing it with the service provider.
This hybrid model thus has the advantage of achieving a balance in the contractual relationship since the financial risk is borne by both parties. It also offers guarantees for the organisation. Well thought through, the agile fixed price reassures the organisation that it will obtain a first version of the product that is reliable and aligned with its business objectives, all within deadlines and on budget.
2. Value as a relevant criterion in an agile fixed price
In the agile fixed price, commitment can take different forms. If the commitment to productivity or quality is of questionable interest, the service provider’s commitment to the value delivered offers a real business advantage.
The downside of committing to productivity
When an agile team commits to the criterion of productivity, it defines a number of “complexity points” to be reached at the end of each sprint by only setting the number of points awarded per feature. For example, when developing a printing functionality, it will award 20 points for printing in PDF, 15 points for printing in Word, 10 points for printing in Excel, etc. At the end of each sprint, it counts the complexity points to know if the objective has been reached or not, this calculation generating a kind of “bonus” or “penalty”.
We believe that the velocity (number of points that a team must complete in a sprint) must, above all, remain an internal tool allowing the agile team to have visibility over its progress. It is risky for the organisation to use it as a control tool: because you are not involved in setting up the points system, you are exposing yourself to the risk that the service provider will artificially inflate the number of points which does not really give you a view of the objectives achieved.
Pay attention to quality commitments!
Another variant, the commitment to quality, is based on the ability of features to pass a battery of tests intended to attest to their “quality”. While this option is sometimes suitable for very technical projects followed by CIOs, it poses a new concern: even though all the tests may be passed, a feature may not meet the user’s needs!
In other words, the commitment to quality raises questions regarding non-functional requirements, whether in terms of robustness, safety, performance or even intrinsic quality. Consequently, it risks causing user disappointment and not producing the expected business results.
The benefits of commitment to value
In the context of this commitment, only the value delivered to the user counts. In concrete terms, the methodology consists of setting up a relative value scale, reasoning in terms of “user value” and “business value” for each feature. This makes it possible to prioritise the release of functionalities in a relevant way, then ensure that the objectives are achieved, using the OKR method, for example.
To illustrate the point, let us take the hypothesis of creating a printing functionality and imagine that we find that 90% of users print in PDF, 10% in Word and none in PNG. In this case, the commitment to value will dictate starting out with a focus on the PDF format, which is most important to both users and the business. The “print in excel” functionality can therefore be abandoned (because there is no added value), even if it means replacing it with another PDF functionality (a “duplicate” functionality, for example) if this appears relevant.
When used in this way, the agile fixed price meets many challenges.
- Delivery: you can be sure that functional groups (or product parts) are delivered to you regularly at the end of each sprint. Ultimately, it offers the assurance of obtaining an MVP (Minimum Viable Product) at the end of the allotted time, that is to say, a first version “that holds up”.
- Temporal visibility: you follow the team’s progress and see the number of iterations made.
- Financial visibility: you know how much time you have used up and know what still has to be done while being able to establish a correlation with the value delivered. This makes it possible, in particular, to stop work on a feature when the return on investment is not there.
3. How do you use the agile fixed price effectively?
As you have seen, prioritise your service providers’ commitment over the value delivered! To work well, the agile fixed price also implies adhering to the values of agility but also taking a few precautions before committing. Here are a few tips.
Outline your requirements broadly
While writing precise and binding specifications is out of the question in the context of an agile fixed price, it is still essential that you define your requirements upstream in broad outlines, such as the target user, the service rendered, expected values, OKRs, performance and/or volumetrics. For example, you need to know how to inform the agile team about the foreseeable traffic when you plan to develop a platform or a website. If these data are unknown, and the traffic turns out to be much higher than the platform can support, it risks collapsing…
Anticipate and carry out the tasks incumbent on you
The agile fixed price involves teamwork and several jobs. While you can count on the service provider to manage the development of the functionalities efficiently, you, on the other hand, must devote time to other tasks. Here are some examples.
- Allocate one or more resources to the projects so that the service provider can have a specific contact, whether in meetings, to maintain collaboration and work on the product strategy, etc. In particular, they will need to present their work to you regularly to get your feedback, so check what attendance time is provided for in the contract!
- Set up and maintain collaboration with the other departments concerned (for example, the DSI).
- Carry out all the work relating to UX and UI, paying attention to constructing fluid pathways and defining the structuring elements as far in advance as possible.
Check the maturity level of the agile team
By retaining an agile team that already knows your subjects, you stack the odds on your side; it can advise and alert you, thanks to its experience on similar projects. From a technical point of view, a mature team will also easily identify the technical solutions to be assembled. This will, therefore, leave them more time to concentrate on their job and bring you the maximum value as part of their support. To check the team’s maturity, do not hesitate:
- on the one hand, to ask them about their understanding of your needs. You must ensure the objectives and the notion of “value” are aligned.
- on the other hand, to discuss with them the technical components they usually use.
In conclusion, the agile fixed price is a good compromise worth considering according to your business objectives. It is not necessarily suitable for “small” projects involving ephemeral products or very technical projects, but it offers many advantages when applied to complex digital projects. If you want to find out more about our support for projects of this type, our experts will be happy to advise you!
