While the Agile way of working is becoming more popular in Indonesia, the best way to ‘contract’ in an agile way is still unknown. Most procurement happens in old fashioned way, with many checkboxes and rules. Contracts are based on the old fixed price model. But in order to reap the benefits of agile in a customer-vendor relationships, we need to change things.
What the agile manifesto teaches us about contracting
The Agile manifesto has a few points that form the basis of the change we need in our contracts:
Working software over comprehensive documentation
In order to create a fixed price agreement, we need to specify everything. In the contract we need to be able to define ‘what’s included’ and ‘what is not included’ in order to avoid conflict. To get there, we need to create lots of documentation. The manifesto points us in the other direction: create less documentation, instead focus your time on create what this is all about: great products.
Customer Collaboration over contract negotiation
Once we have all those requirements in large documents, we need a large contract to define all the exceptions. What if we don’t deliver on time, what if some requirements are missed or not fully implemented, etc. We spend days, weeks or months negotiating the contract. Whereas results become better if we focus on collaboration instead. The direction to take here is to create win-win contracts that benefit both sides. And focus on a good relationship instead of ‘what was agreed’.
Responding to change over following a plan
This may be the most important statement influencing the contracting. Traditional contracts focus on ‘fixing’ everything: requirements (what do we need to build), time (when is it ready) and quality (according to what standards). This contract forces us to make long plans that people then follow. We prefer not to deviate from any of the 3 variables, because that leads to big discussions (and new contracts). In Agile, we welcome change. We know that if we change based on ‘insights’ from users, we’ll build a better product. But as this change goes directly against the traditional contract, we must change that contract for agile to work.
The golden triangle
The below, well-known diagram, shows the biggest differences between the traditional way of working and the agile way.
In fixed price, waterfall contracts, requirements are fixed. The resources (team size) and time are estimated; since we MUST finish all the requirements, chances are that we’ll need more people and/or will need more time (deadline overrun).
In agile, we fix the resources (stable team size) and the time (into time boxes). We estimate what features we need and understand that they will change based on new insights over time. So while time and resources are fixed, features or scope are not. The goal in agile is to delivery the ‘maximum value’ within the timebox (e.g. within the timebox of a release) given the resources (team size) we have. This maximum value is delivered because the product owner (client) puts the highest value items on top of his backlog and these are ‘produced’ first. This results in value being shipped early and frequently.
Now, the challenge is that ‘buyers’ don’t like these changing requirements, because it is hard to fix things in a contract. To accommodate the changing requirements, we need a different instrument.
This notion of varying functionality does not sit well with many people. They want a price for the whole system, not some random subset of the easy parts; they also want a written contract to hold the project accountable to. However, in order for any software project to achieve this, time-consuming (and costly) extra analysis must be undertaken, carefully crafted specifications produced and substantial contingencies incorporated to accommodate reasonable and unforeseen changes, issues and setbacks. People can have fixed scope and firm estimates, but the cost is paying for activities that don’t add much value after going live and for inflated estimates to buffer uncertainty.
The below diagram, shows the spectrum of contracting options we have at our disposal.
The traditional contract is on the left side: everything fixed. The risk is moved completely to the supplier, because all the requirements are fixed and the supplier has to deliver those. If there are changes, the fee for that is specified in the contract and must be negotiated for every change.
On the right side, we have the time and material contract. The customer just pays the time for the development team. All the risk is moved to the customer. In this version, the vendor doesn’t mind changing things as they’ll get paid for every minute spent. Customers engaged in fixed price contracts desire more flexibility. Customers engaged in time and material contracts want to add SLA’s, guarantees on quality, on time delivery and clauses to minimize their risk.
In between are some variations that could provide a ‘middle way’.
In the light of ‘collaboration’, let’s look at both extremes. The traditional fixed price contract takes time to establish. We spend months to analyze and document all the requirements (often the vendor doesn’t get paid yet, because it’s a normal exercise to reach a proposal). Then we spend time to negotiate the contract and fix everything in a statement of work. We agree not to change the SoW and make clear agreements on what happens in case of change requests. Once the ink is dry, the client can ‘sit back and relax’, because the vendor has to work hard to deliver. The incentive for the buyer to engage closely with the vendor team is low, because ‘all has been agreed already’. The vendor works in a vacuum and once the first deliveries or milestones happen, the client wakes up. Usually this waking up means they come with changes and complain about the slow progress. This is not the ‘collaboration’ we are aiming for in Agile.
At the other extreme, the customer is on top of the vendor teams because every minute costs money. The vendor is more comfortable and team members might lack the incentive to work hard. There is even a counter-incentive: the slower the work, the more money they get. Any delay will cost the customer money, to the benefit of the vendor. Of course, in most cases, vendors are motivated to create a great product. If they deliver high quality and form a good partnership, they’ll ensure long term work. But if that motivation isn’t there, things can go awry.
In agile contracts, we want to find a ‘middle way’; a contract that shares risk between parties, that gives parties a clear incentive to become partners.
The middle way
Every company will need to find the best ‘middle way’, given the context of procurement regulations, laws and preferences. The specific contract for your context is somewhere on the spectrum between fixed price contract and time and material contracts.
The guiding principle to all agile contracts should be: collaboration. Most contracts are based on the idea that we have 2 parties and we have to ‘defend one against the other’. While there is merit in this thinking, in agile we want to work towards the idea of ‘one team’. One team means that we see the constellation as a group of people working towards a shared goal. It shouldn’t matter whether a team member is employed by company a,b or c.
In a traditional contract, our thinking and language is guided by ‘us versus them’. We’d add clauses like: ‘if the delay is caused by the vendor, vendor will not charge customer for additional costs’. In reality, some delays in a project are caused by person A, sometimes by person B. It’s not always clear who caused the delay. If we want to get to a culture of collaboration without blaming each other, we must avoid such phrases.
Below are some categories of contracts that can be applied:
Fixed-price agile contract
This category is a good ‘starting point’ for agile contracts. It is on the fixed price side of the spectrum and therefore often makes traditional procurement and law departments more comfortable. It is a good starting point to build a more agile collaboration and contract; it could be applied to the full collaboration or for the initial releases (so we can move towards a more fully agile form incrementally).
In the fixed-price agile contract, we ‘fix’ the price for the project and semi-fix the scope. In the traditional contract, the scope is 100% fixed. In the fixed price agile contract, the initial scope is estimated.
These are some of the ingredients that go into the contract:
- The customer and vendor create a backlog of user stories to be included in the product. If it’s a big product, the user stories to be included in the first release are grouped.
- The customer prioritizes the backlog and puts the high value items on top.
- The vendor estimates the backlog items with the knowledge gained so far. If the product is split into releases, the items are grouped per release, so an estimate can be made per release.
- Vendor provides a price for the product or release with timeboxes.
- The customer dedicates a product owner to the work who participates actively in the events during each sprint.
- Changes may not be made during the sprint
We then make clauses to accommodate change. There are roughly 2 clauses to control scope and change:
- Zero cost changes
These changes are ‘swaps’ of user stories. We swap 1 story with another story of equal size. A simple example: we have agreed to deliver 200 story points in the next release. In that, we have a story of 10 points. Based on the initial sprints, the product owner (customer) decides that another story, which was estimated at 10 points by the vendor team, has a higher priority. The team then replaces the old 10 points story with the new one (with approval from the product owner). This swap has no impact on the total budget agreed for the release and the product owner has made the decision that this user story is more important.
- Change with a cost
Bigger changes or user stories that cannot replace an old story and must be added, need to be added at extra cost. In the above example, this means that we have the 200 points for the release. The product owner believes that all 200 must be finished in the release and the 10 point story needs to be added, making the total 210 points. In the contract, we can agree on a price per point or a price per sprint. The 10 points are then added as ‘extra’ to the initial budget of the release. This means we need to add a sprint to the initial number of sprints we had planned for the release.
- Change with a reduced cost
The change with a cost option creates risk for the customer. It also provides a counter-incentive for the vendor, who profits from extra work and delay. To balance this risk, the changes that come on top of the original release backlog, could be charge at cost-price by the vendor. The price per point or per sprint for work outside the original backlog will be lower than the original rate. This way, delay costs the customer less money, while the vendor doesn’t earn anything (and has an incentive to minimize changes and finish things in time).
Agile Contract - Indonesia
Sprint based contract
The sprint based contract is a fairly simple one and is on the time and material side of the spectrum. The vendor simply invoices the customer for the time spent during the sprint. The time spent could be fixed (based on the number of team members) or variable (based on the real hours spent during the sprint).
The only difference with the time and material contract is that we base invoices on the time box of the sprint (instead of monthly). This means all the risk is on the customer. Some elements can be added to the contract to balance the risk.
- Cancellation of contract clause
While the vendor is comfortable invoicing the hours spent per sprint, as a customer, we may want to give them more incentive to perform. A vendor team can become complacent thinking that their job is to just ‘put in the hours’. We want to keep people focused on delivering value to the customer (or even to the end user of the system we’re building). To stimulate this, we can add a clause that enables the customer to end the contract if the sprint output is unsatisfactory. As a vendor, we want to do everything possible to avoid this, since our team will be ‘on the bench’ without a warning.
To ‘soften’ the cancellation clause, some additional elements may be added:
Satisfaction score: each sprint we track a ‘satisfaction score’ from the both sides. We could rate the satisfaction on a scale of 1 to 10. If the rating is below 6 for 3 sprints or more, customer has the right to cancel the contract without any notice period. The same holds true for cancellation from vendor side.
Notice period: the customer has a notice period of 1 or 2 sprints. This means the customer can cancel the contract without stating a reason, but will need to pay the full amount for x sprints. This enables the vendor to seek a new contract for the team.
Output or outcome based contracts
This is the most ‘agile’ variant and also the hardest to establish. In this type of contract, the customer pays only for value delivered. The key challenge is to define ‘value’ and come to a fair assessment of the value delivered after each sprint.
It’s worth noting the difference between output and outcomes. Input is the basis of the above contract forms: input = labor hours. Outputs are deliverables (e.g. user stories or features). Outcomes are the business results achieved with the product; usually defined in monetary value or customer satisfaction. Outputs contribute towards the outcomes. Inputs refer to the resources used to deliver outputs.
In the ideal world, this contract category would be based on outcomes. But it’s always challenging to create a direct link between the outputs of a sprint and the business outcomes achieved with them. This link can be achieved by making the vendor a shareholder in the product or providing them with incentives upon achieving certain business outcomes ($ turnover, # active users, etc).
The output based contract is a bit more straightforward. These are 2 examples of an output based collaboration:
- Pay for story points delivered
Customer pays for the story points completed during a sprint or release. In the earlier example, the vendor committed to delivering 200 story points within the release. At the end of the release, the team delivered 150 out of 200 points or 75% of the agreed outputs. The invoice the vendor sends the customer will be 75% of the time spent.
A variant of this can be to invoice the full amount agreed, but the 25% has to be delivered at cost price. In that case, the vendor doesn’t make profit on the ‘delayed’ user stories.
This logic may be applied to delivery of value in each sprint, so each sprint, an invoice is issues for x% of the agreed amount. In reality, team velocity fluctuates sprint by sprint and a team can recover the lost productivity in the next sprint(s). Applying this logic to a release which includes x sprints makes the administration easier and gives teams an incentive to make the agree ‘target number of points’.
- Pay for satisfaction delivered
An alternative way is to measure customer satisfaction. The easiest ‘satisfaction’ is from the customer to the vendor (it could also be based on satisfaction of the end user of the system). Each sprint, the customer will rate the delivery and/or collaboration on a scale of 1 to 10. Parties agree that if the rating is 8 or higher, the normal amount will be invoiced. If it’s between 6-8, 75% will be invoiced; below 6, 50%. Or any variant in categories. This gives the vendor a clear incentive to keep the customer happy with the product delivery and collaboration.
- Incentives for reaching business outcomes
The above logic could be supplemented by some incentives upon reaching business outcomes. This creates a direct link between the work of the vendor and the benefits for the ‘real’ users of the product. Let’s say we are building a banking app for a bank. The app is new and the bank wants to release the app soon because competitors are launching similar apps. One incentive could be to give a ‘bonus’ to the vendor upon launch. Another could be to give a bonus based on the number of active users of the app.