You have probably been in the position where you had a project and the money to fulfill it, but not the manpower or knowledge to do it. You would’ve had to engage a supplier to get the work done. If we look at the Agile Principle ‘collaboration over contract negotiation’, we notice that while a contract is necessary, collaboration is more important. Paper is just paper if all the parties aren’t actually involved and invested in their work dynamic.
Fixed scope, fixed budget, fixed time contract
For decades companies and suppliers would work together on a fixed scope, fixed budget, fixed time contract. Before things were so uncertain and complex we might have been able to estimate scope, time and budget quite well, but no longer today.
Or not even. Imagine the simplest adjustment to do in your house. I bet you have all been in the situation of hiring a contractor with this formula of fixed scope, time and budget and then you’ve discovered, when they were halfway through, that some extra work needed to be done. Maybe an extra issue was ‘hiding behind the wall’ or suddenly you came up with an extra request once you saw ‘how things looked like?’.
You must have felt that you couldn’t or didn’t even dare to ask for more or even if you did you would have seen reluctance from the supplier. Or even worse, they could have said yes, but then did a quick sloppy job just to be done with it or they could have potentially even disappeared before finishing it. I mean, you always have the strength on your side as you can decide ‘not to pay’ if the ‘contract is not fulfilled. But for me, those things always end with a wry feeling as if you both screwed over each other. And this adjustment in your house was supposed to be a simple and certain job! So imagine when it gets uncertain and complex!
The above story describes a standard Company-Supplier contract that is fixing scope as well as time and budget. It is the least Agile thing to do as it means that the supplier takes all the risk and you take none. The only way to proceed here is for the supplier to build a time buffer:
- When surpassing the time buffer you come upon that risk of having the discussion on changes or even getting the quality of the work go down as the supplier wants to finish the job faster.
- And even if they finish earlier, they could still invoice you the total amount. Finishing earlier might give them the incentive to work faster but with less quality.
It feels like a lose-lose scenario.
Time and Material contract
In a VUCA world, you never know exactly how much time or money a project will demand. As a company, the most Agile thing to do is taking on all the risk upon yourself.
This means that if you don’t have the manpower or knowledge to take on the project, the best thing to do is hire people from your supplier on time and materials basis and fully integrate them into your team. It will allow you to play around with scope, time and budget throughout the entire project.
You basically create a team of people working together towards a common goal independently of how they are being paid or have to allocate their time. You keep any decision for a way forward into your own hands. There are no expectations toward the supplier but perhaps supplying you with great people!
An Agile Contract
Sometimes we find ourselves in between these two options. We come across two different entities, the company and the supplier, that make it necessary to talk about contracting in the sense of “developing an alliance towards a common goal”.
Shouldn’t it be better if both of you could get involved in a more equivalent way, let’s say both of you share the risk? You decide together and collaborate all along the way?
Only when the customer and the supplier are open to letting go of either scope, time or budget, can you get started on a more Agile path. Here is where you set up an Agile contract. An Agile contract is nothing more than the support of good collaboration and good agreements.
Take a look at the Agile Principle: ‘collaboration over contract negotiation’. It’s explicit that it takes good agreements to make good friends. So when establishing agreements, we put focus on developing a trust-based relationship with our supplier. It is important to work towards a common goal and that both parties are “all in this together”.
Once this is understood, an Agile Contract comes down to making agreements on tolerances, as well as escalation reasons and changes in scope, in which both company and supplier share the risk. By comprehending the principles and values that the Agile Contract relies on, you will be able to establish a contract that is actually helpful.
Before we explain what an Agile Contract is, you should already have some knowledge about Agile estimating and planning; what is velocity, what is a burndown chart. We can recommend Mike Cohn’s book “Agile Estimating and Planning”.
Tolerances
When we talk about tolerances we are discussing percentages. The allowed schedule and cost deviation from baseline. Ten percent, twenty percent? If there’s a deviation from the agreement on the velocity, on how many points per sprint were supposed to be accomplished, then the customer and the supplier have to sit down and go over events.
- Schedule tolerance: the tolerance for the maximum allowed negative schedule of the project planned scope. It is tracked via the Product Burndown chart, which is updated at the end of every Sprint based on the user stories accepted by the Product Owner
For instance: say you agreed on an average 10 points burned velocity. In the range between 8, 9 and 10 points burned in a certain sprint will be within the tolerance. Everything below we’ll need to sit down together, go over events and align on the next steps to take.
- Cost tolerance: the tolerance for the maximum allowed negative deviation of the planned cost of the project. It is measured at the end of every Sprint
It’s likely you’ll end up combining both schedule time and budget cost. It may be that your velocity has dropped, but the reason is that everyone is on leave or sick and so your budget has not been touched. Or perhaps your velocity is just on track by 10 points but because you are paying twice as many people to do the work. Both schedule and budget go hand in hand.
Escalation State
When tolerance is exceeded, the project enters what is considered to be an “Escalation” state (“yellow” state). Company and supplier can define a recovery period after which if the problem is not solved it could potentially end up in “red” state, but we will discuss that further on in the article. For now, In the “yellow” state, there is some sort of problem or blockage that the customer and the supplier need to address and have a conversation about in order to identify what’s causing it.
This type of situation is one of the main reasons you create an Agile Contract, sort of as an Agile Contract is an agreement between the customer and supplier on how to proceed when the deviation tolerance is exceeded in order to exit the escalation estate.
There are different potential root causes of an Escalation State, for example:
- The team is blocked.
- The team hasn’t finished the work (it’s almost done).
- The team has been working on things that are not important.
- The work has been underestimated and is more complex than foreseen.
- The team is underperforming.
- The velocity is on track by the agreed 10 points, but because you are paying twice as many people to do the work.
After identifying the cause of the escalation mode, the next step is to find the most suitable proceeding to get out of it. The customer and the supplier have to meet to acknowledge the situation and to reach an agreement on how to proceed. It will all depend on whether the delay is recoverable or not:
- Recoverable delays: For instance, if user stories have not been delivered but the work the team has done is valuable, then the delay might be recoverable and the project is still on track. It only needs a small adjustment. The company can reduce the scope while they still deliver the right amount of value within the timeframe.
- Unrecoverable delays: A delay is not recoverable if through reducing the scope no valuable product has been delivered within the timeframe. In this case you could decide to extend the project duration. If so, you’ll have to take into consideration your particular circumstances, maybe you have a strict deadline and the additional cost for the delay is not something you can afford.
Often reducing some scope in combination with extending the project a little and spending a bigger portion of the budget, will be an acceptable outcome of an adjusted agreement.
In what cases should the project or contract be canceled?
Remember that we mentioned the “red” state? Well, usually when you are discussing canceling the project it means that you have entered into this “point of no return” moment.
It is ought to the customer and the supplier to assess, but there are usually three circumstances or a combination of them that would lead to this resolution:
- either the escalation state has been ongoing and is unresolved for longer than the agreed recovery period,
- or the project has exceeded a 50% planned schedule or 50% over the planned budget that was agreed upon in the contract,
- or the product isn’t capable of hitting the market in time nor reaching the right amount of value to beat the competition.
Based on the above, the company might decide to cancel the contract with the supplier, maybe hire another supplier to continue.
Perhaps the project gets canceled altogether. In this case, even if it might seem like failure, better to stop early than to keep on spending money on a product that will eat your budget or will not hit the market on time. In a sense, this is the ultimate scope adjustment. Cancelling the project will free you to spend time and money on the next most valuable thing.
Changes in the scope
Any new request must be estimated by the Team. Suppose there were a number PBIs beforehand with a total of worth of 100 Story Points in the Product Backlog, then you can agree to:
- Exchange the new request to other PBI’s of equivalent size while staying within the 100 Story Points.
- Enlarge the project size by extending the project duration and the contract. In this case, you would increase the budget.
And what if both schedule and cost tolerance has exceeded positively?
Hey, not everything is bad news! It could happen that you deviate from your tolerances on schedule and cost in a positive way. Maybe your team speeds up like Flash or even develops Sherlock’s deduction abilities and manage to discover their best working skills. Either way, it is important you consider these possibilities when making an Agile Contract, cause, while being good news, a change in direction will need to be made.
Let’s bring back for a minute the earlier example of a 2 story point tolerance. You agreed on an average 10 points burned velocity. In order to comply with the tolerance, you should burn within 10, 11 or 12 points. Everything above, the company and supplier will need to get together, go over events and align on their future steps.
The company could choose to add scope or even change the original PBi’s in scope, while staying within the timeframe and budget, or stop the project earlier and maybe pay less. Agreements on the possibilities are better to be agreed upfront.
And don’t forget…
An Agile Contract, in addition to Tolerances, Escalation State and Changes in the scope, will also cover several other topics, such as the use of Scrum and Agile as a framework, roles and responsibilities of Scrum applied to the customer and supplier, length of the Sprint and when Sprint events take place. Among others, you will also find the standard issues around target planning, price, invoicing and bank guarantee.
Have you been struggling on making an Agile Contract and you need a hand? We offer Agile contract templates that could help you! Check our consulting and coaching services and let us know.
We also have some in-house trainings and non certified courses that could be of interest for you, contact us!