This article is intended as a reference in the search for the most appropriate type of Agile contract, given the dynamics between the client and the contractor.
Content
Challenges of Agile contracts
In the case of development initiatives, the constant flow of new knowledge (and therefore requirements) requires the operator to continuously coordinate the direction of development with other stakeholders. From the point of view of traditional contractual relations, this dynamic and lack of coherence is problematic, as it is difficult to formalise it in a contract.
Agile contract types are attempts to spread risk evenly between the client and the contractor in an unpredictable development environment where the product is developed incrementally.
Example: a customer wants a solution to a business problem. The problem is known, but the preferred solution and the path to it are not. Such an initiative will require a cyclical incremental approach from the contractor. Each successive development cycle will build on the lessons learned from the previous one. The direction of development and the identification of the most appropriate solution will therefore adapt accordingly.
In such a situation, if the customer insists on a fixed contract price, the entire risk will be transferred to the contractor. Because of the many unknowns, it will be difficult for the contractor to give an accurate estimate of the development costs. To compensate for this risk, the contractor will have to increase the price significantly (with a contingency reserve) or risk a loss. This is not a desirable situation for either the client or the contractor.
Let’s take a look at some of the types of contracts that are suitable for cyclical development work in different contexts. I will use their English names, which will help those interested in the topic to find further resources. In addition, it is difficult to find established equivalents for certain terms in Slovenian.
Types of Agile contracts
Time & Material
It is often considered a “true” Agile type of contract. In this type of contract, the client pays the contractor (from the project budget) according to the hours spent developing the solution. This is usually further limited by the completion date of the work.
A common criticism of this contract is that it favours the contractor and encourages scope creep. In my opinion, this is not true, as iterative development cycles are short and the client is constantly involved. The development process is transparent, so that the contractor basically has no possibility to hide the development of unnecessary and unapproved functionalities (the Product Owner is the client’s agent).
In addition, under such a contract, the customer has the option to terminate the cooperation at the moment it considers that the output of the iterations is no longer delivering sufficiently high business value.
Features:
- The price is based on the hourly rate of the contractor.
- The contract contains only an indicative specification of the solution.
- The Customer may terminate the contract at any time.
For:
- A well-understood type of contract.
- Suitable if the vision and the solution envisaged are not well defined.
Against:
- It does not provide objective milestones to measure progress. This problem can be avoided by constant cooperation between the customer and the development team (Product Owner). Thus, milestones become customer-approved functionalities at the end of each iteration.
- It offers the operator the temptation to use time inefficiently. Agile requires a certain level of trust between stakeholders. If the Customer is part of the development team (Product Owner), trust is built more quickly.
A "scary" case
Let’s describe another scenario that will scare any client manager.
A scared client: “I can’t sleep. What if the contractor “winds up” the clock and doesn’t develop a solution by the due date and within the budget? Oh my goodness!”
We of course sympathise deeply with the manager, but we feel obliged to explain to him some facts about the nature of incremental development and why it is beneficial for him.
- Since you, as the client, know the problems you are facing but not the best solutions, you have left this task to a professional contractor. You rightly rely on them to use all their knowledge and resources to find the best solutions to your problems.
- Some of the contractor's proposals you accept as they are, others you reject, and still others are promising but still need to be refined by the contractor. This is "iterativity" in iterative development - the contractor checks his ideas with the client and refines them until the client is happy with them.
- The result of this process is a multitude of potential solutions to your business problems.
- Because not all the problems you face as an organisation are of equal urgency, you have prioritised them according to their business value. Naturally, you want the problems whose solution is of the highest value to you to be solved first.
- The solutions envisaged to these problems are also prioritised. This is the so-called Product Backlog. At the top of this list are potential solutions to your most pressing problems, and lower down the list as we go are solutions to less and less pressing problems.
- The contractor will first develop solutions at the top of the Product Backlog and slowly move down the Product Backlog to solve smaller problems.
- The contractor will break down the solutions into functionalities, which will also be checked with you before development. You may approve them, but they may still need to be adapted. The contractor will present the developed functionalities to you at the end of one of the next iterations. In this way, the contractor adapts the developed solution to your requirements on an ongoing basis. These requirements are not static, but are generally modified and updated in the light of the innovative solutions proposed and already developed, which have provided you with new insights into the issues at hand. And rightly so. In a classic contractual relationship (fixed contract), you as the client do not have the flexibility to exploit the business opportunities revealed by the developments to date. Will you sign a contractual addendum for each new opportunity identified and adapt the overall project plan?
- Once you are happy with the solution you have developed, you can immediately integrate it into your workflow. You won't have to wait until the project is complete to receive the full set of solutions (important and less important).
- The consequences of this iterative development process are:
- As a client, you get a solution that is tailored to your needs and solves your business problem as efficiently (not just effectively) as possible.
- You get solutions faster than in a fixed contractual relationship, because the contractor's path to a solution is shorter and more linear, thanks to the constant collaboration with you. If solutions are checked only at milestones or even only at the end of the project, any corrections require a huge amount of effort and wasted time. In this case, we often have to rewrite the entire code based on a wrong assumption.
- As it is impossible to predict the time/cost of development at the beginning of the initiative because of all the unknowns (we are not building a house, we are developing a unique solution), we don't even bother with that. The contractor will develop the most valuable solutions for us (from the top of the Product Backlog) first anyway. The fact that all solutions will run out of money is not a problem, because at the bottom of the Product Backlog there are problems with less business impact.
- If we really want to solve the remaining problems in the backlog, we can grant the developer additional funding. In practice, this will almost never happen, as new business opportunities with higher business value will emerge during the development process and will be more worth developing than the aforementioned "leftovers" from the bottom of the Product Backlog.
In the case of Agile Development Initiatives, the client allocates a certain amount of resources to the development and sets an indicative timeframe for implementation. The scope of a solution that does not yet exist is only a guess at this point. There will be no undue exploitation on the part of the contractor, as we as the client are constantly involved in the development process in terms of validating ideas, solutions, prioritisation, user testing, finding new ideas, answering questions from developers and monitoring the development at Agile Ceremonies. Yes, I am talking about the fact that for the best result of the initiative, the Product Owner/Product Manager has to come from the client’s organisation. At first glance, this requirement seems expensive, but think how much a failed product initiative will cost us.
Frightened client: ‘But our director will never approve the funding if he doesn’t know what we’re going to get for it. We don’t work like that. Our sector is too regulated/complex/specific.”
That’s right. Your Director is right. And you will believe it until your biggest competitor proves you wrong.
Graduated Fixed-Price
The contract provides for different hourly rates depending on the date of completion by the contractor. Completion in this context means the achievement of the client’s business objective.
If the Contractor develops a solution early, the Contractor will be charged at the higher hourly rate. This way, both the client, who got the solution early, and the contractor, who added more value, are satisfied.
However, if the contractor is late, his (total) work is charged at the lower hourly rate. This protects the client from excessive costs and encourages the contractor to meet deadlines. If the delay is due to unforeseen circumstances on the part of the contractor, he will still be paid for his extra work, albeit at a lower rate. This reduces the possibility of conflict between the stakeholders, which would arise if, from a certain point onwards, the contractor had to work for free in order to fulfil the contract.
For:
- It gives the contractor an incentive to work faster.
- It gives the contractor an incentive for quality, as “bug fixes” are time-consuming.
- The risk is shared equally between the client and the contractor.
Against:
- Quality standards (Definition of Done) must be well defined to avoid disagreements in the validation of developed functionalities (Sprint/Iteration Review).
- If the limit is only of a date nature, it offers the contractor the temptation to “park” unused developers in the project in question.
A variation of this contract is to set pay grades according to the business objectives achieved. Example:
Additional safety mechanism
During development, there will undoubtedly be requests for change from the client (due to newly identified opportunities) – this is the nature of development work. To avoid disagreements with the contractor, it is useful to state in the graduated fixed price that:
- The price class is determined only according to the initial volume of the backlog
- Additional work is charged according to the “Time & Material” principle.
In such a relationship, the contractor maintains the motivation to integrate new requirements during the development cycle, while the client maintains the flexibility of development that will give it the maximum ROI.
Cost Plus
A notorious type of contract, but manageable under the right conditions. In addition to the development costs, the Client pays the Contractor a fixed monthly or quarterly bonus, which is the Contractor’s profit (optional), and an additional bonus for successful achievement of the project’s objective.
The sub-categories of this contract are:
- Cost-Plus Fixed Fee: A fixed fee set in advance.
- Cost-Plus Incentive Fee (CPIF): The contractor receives a higher reward if it meets or exceeds the targets.
- Cost-Plus Award Fee: The contractor receives an award based on potentially subjective criteria such as quality, responsiveness, scalability, etc..
For:
- If the conditions for the reward are well defined, it motivates the operator to develop more efficiently, as the added value of the reward per unit of time tends to decrease with development time.
- It encourages good practice on the part of the contractor (refactoring, TDD, etc.) as it is motivated to achieve rewards (if these are objectively high enough).
- Suitable for development initiatives with vaguely defined objectives and consequently many requests for change.
Against:
- The contractor does not have a strong incentive to be efficient, as more work means more money. For this reason, the reward is often linked to a specific factor (time, quality, NPS…).
- If the objectives underlying the reward are not well defined, it can lead to mutual recrimination between stakeholders.
- More control by the contracting authority is needed, as the contract encourages less transparency in the contractor’s cooperation with the contracting authority, due to the development costs being covered on an ongoing basis. This is avoided by defining the way of cooperation (co-location, Product Owner is an employee of the client, implementation of Agile ceremonies, etc.).
- If a project becomes more complex than initially expected, the contractor often wants to negotiate a higher value for the award.
- It is difficult for the customer to judge the indicative development costs in advance.
Safety mechanisms
- As with the graduated fixed price, rewards can be linked to a percentage of business targets achieved.
- It is useful to set a maximum level of resources for development.
- If the number of critical errors exceeds a certain threshold due to poor quality, the contractor may be subject to a reduction in the allowance or bonuses for subsequent iterations.
Target Price
The contract is similar to Cost Plus with additional restrictions. The project objective is defined as the effort that the contractor will put into the initiative by a certain date. A minimum (often) and a maximum number of hours (hence the Target Price) are set for the effort. The final reward takes into account the level of trust and the success of the cooperation between the contracting parties. If the contractor achieves the target ahead of schedule and at a lower cost than anticipated, the savings are normally split 50/50 between the two parties in the form of an additional award.
In such a contract, the objective of the initiative does not have to be quantitative (20% increase in traffic), but can be more inspirational (new ways to increase traffic).
In a Target Price contract, both stakeholders share the risk roughly equally.
For:
- It encourages collaboration and active scope management. Especially in terms of minimising scope to functionality only, with a real positive ROI. Both the client and the contractor have a financial incentive to maintain an optimal scope.
- Greater transparency of work. As a result of the previous point.
- The client and the contractor share the risk through shared savings or pain-gain share.
- The target price is not a fixed limit. It allows new requests to be accepted if they have commercial value, without the need to sign annexes.
Against:
- It is more suited to “qualitative” initiatives that offer new information about the subject, generate new breakthrough ideas or are feasibility studies.
- When the scope changes, the contractor will often request an increase in the hour limit and a delay in the completion date.
- As the price for each functionality is not fixed, subscribers may become too relaxed, which encourages scope creep.
- Such a contract requires the buyer to take an active part in the development. If there is no participation, the contractor assumes most of the risk and the model becomes unfair.
The Target Price variant of the contract has a target price and a maximum development cost (cap). The additional award is determined according to the target cost cap. Below the cap, the savings are split in half between the stakeholders, above the cap (up to the maximum cost limit), the contractor continues to work at half the hourly rate.
Money for Nothing and Change for Free
This type of contract was not invented by Pink Floyd (we know because it doesn’t rhyme), but by Jeff Sutherland, one of the authors of the Agile Manifesto. We are talking about a standard
The request is reasonable, as the Product Owner, who is the customer representative, is the only one who can reprioritise the Product Backlog. If the customer is not involved in this activity, the contractor does not have a dynamic direction but has to rely on the contract. Reprioritisation is free of charge as long as the scope of work remains the same.
The client also has the option of ending the project early when it considers that the ROI no longer justifies the investment. This is standard practice in Agile projects, as the required functionalities are ranked by business value in the Product Backlog. As we move down the backlog, sooner or later we reach a point where the development of the functionality no longer justifies the cost of development. In the event of early termination, the customer shall pay the contractor 20% of the remaining contract value.
The “Money for Nothing” clause protects the contractor from the sudden shock of contract termination and removes the need for a price “buffer” in the estimate.
For:
- Suitable for environments where there is good and continuous cooperation between the client and the contractor.
- It allows for real-time changes to the scope and early termination.
Against:
- Potential for conflict if the minimum involvement of the customer in the development cycle is not defined (Product Owner, Sprint Review,…).
Fixed Price Work Packages
Instead of the work being assessed as a whole, the work is divided into smaller parts called Work Packages. A contractor may take on several Work Packages for development. After the first Work Package has been realised, the price for the next Work Package may be negotiated. The new price, if any, shall be influenced by the complexity and risks identified to date.
By dividing the work into relatively small packages, the risk of overestimating or underestimating the development effort is reduced. The contractor’s risk is limited to the package currently under development and the client is provided with a more realistic estimate of the cost and need for reprioritisation. A variation of this type of contract is called a “Fixed-fee contract per iteration or story” – the name explains the difference.
The basis for the packages is usually a Statement of Work (SOW) which is derived from the Waterfall methodology and is rare in Agil.
For:
- It allows the customer to re-prioritise packages on an ongoing basis in line with previous knowledge and costs (Backlog Refinement).
- It allows the contractor to adjust the price in line with ongoing learning and newly identified risks.
Against:
- To create Work Packages, we need a pretty good idea of how we are going to achieve the goal. This is rare in Agil. The solution would be for a partner to take on only one or two Work Packages, while further Work Packages are gradually shaped according to the findings of the Work Packages that have already been implemented.
DSDM contract
In 2017, the Agile Business Consortium, the custodian of the DSDM methodology, released the current version of the“Agile Project Framework Agreement” model contract.
This contract provides for a fixed price for the project, with a variable scope and the condition that all “must have” functionalities are developed. Must haves in this context are the so-called “feasibility” and “foundation” phases. Subsequent phases are financed according to the findings of the first two phases.
For:
- Although it is written with the DSDM methodology in mind, it contains most of the elements that a good Agile contract should have.
- A comprehensive treaty.
Against:
- It contains the terms “good faith” and “reasonable”, which have no legal weight. Replacing them with concrete criteria (e.g. “content of each sprint backlog”) could solve this problem.
Note: The DSDM is the only concrete model contract in this article. There are also references to LexisPSL, GDS DOS, Flexlite 0.1, Danish K03 and Norvegian PS-2000. Interestingly, access to these samples is quite difficult.
Combined contracts
These are contracts that contain elements of several of the above types in terms of addressing their shortcomings.
A few examples:
- Graduated Fixed-Price contract with a Cost Plus clause to incentivise the contractor to achieve higher quality.
- DSDM contract adapted to the Kanban lifecycle.
- Fixed Price Work Packages with a Cost Plus clause to incentivise the contractor to achieve high quality.
- Time & Material contract with Fixed Price Work Packages clause, which would allow for variation of the contractor’s hourly rate for differently complex larger packages within the initiative.
- Target Price contract for a feasibility study with a Cost Plus clause to encourage the contractor to realise a prototype solution.
- Money for Nothing Change for Free contract with Target Price clause, which would limit the initiative to the maximum investment regardless of the ROI of as yet undeveloped functionalities.
Trends and recommendations for Agile contracts
To summarise the basic differences between the traditional and Agile contracts:
In this context, lawyers distinguish between two types of contract:
- Negotiated contracts. Such a contract ensures productive cooperation throughout the project.
- Contracts that are subject to legal action. Used for harm reduction – “When shit hits the fan”.
I think that Agile contracts should be drafted primarily in the spirit of the first type of contract. Provisions of the second type, however, are written with a view to limiting major deviations. In doing so, care must be taken not to create a “conflict of disputes” by using terms such as “good faith“, “best endeavours” or “good industry practice“.
Here are some of the features that the new types of Agile contracts should take into account:
- They contain a vision.
- They contain the project’s objective in terms of a business result. Sometimes this is not possible (too many unknowns).
- They allow for flexibility in implementation (roadmap).
- They describe the framework structure of the project (Scrum, Kanban, LeSS,…), roles and deviations from the standards (e.g. introduction of an integration team in the LeSS framework).
- They allow for scope changes within the same workload and with allowances for unforeseen work.
- They define quality (Definition of Done) and allow it to evolve.
- They contain a cost range or cost limit.
- They describe the processes for scope and cost management.
- They describe how the client and the contractor work together, the decision-making and escalation pathways.
- They describe the points of verification of the implementation (Sprint Review, Product Owner involvement).
- They allow for early termination or renewal of the contract.
Recently, I have seen attempts to implement Agile initiatives without a formal contract between the client and the contractor. This relationship is based on a high level of trust and occurs mainly in Scaled Agile environments of larger organisations, where teams from different organisational segments collaborate in this way. It also occurs between partner organisations that are already strongly interconnected (or interdependent) in a segment.
Adaptation of customer processes
I would also like to stress the following. If an organisation that opts for Agile outsourcing is essentially hierarchical and runs its projects according to the waterfall methodology, it will have to adapt some of its processes to the Agile provider. I am thinking in particular of the market research and backlog prioritisation functions carried out by the client’s product manager, and of allowing feedbacks to developers from end users (iteration review). Allowing direct communication between developers and end users is not a bad idea either.
I hope you find this article helpful. But we are certainly not done with this topic yet. Agile contracts
The article is also a supplement to the Product Owner course material , where we usually run out of time for a detailed overview of contracts in the Agile Budgeting chapter.
