One of the challenges often discussed in the agile community is ‘how to create contracts that support agile development’. Let’s look at some of the options.
The traditional, fixed price, waterfall contract
Most budgeting and legal frameworks are based on the traditional waterfall model. The goal in traditional contracts is to
A. specify ‘everything that needs to be built‘ and
B. distribute the risks of non-compliance with ‘everything that needs to be built’ between 2 parties
The underlying assumption here is that we can describe ‘everything that needs to be built’. Once we’ve described that, we can agree that if there is ‘extra work’, it comes with a certain price. We can also agree on what happens if we cannot build ‘everything that needs to be built’. As most people in the IT industry know, we inevitably need to argue about the extra work and the non-compliance. This usually puts pressure on the relationship. And the focus becomes compliance instead of building great software.
Working software over comprehensive documentation
Instead of spending weeks or months describing ‘everything that needs to be built’, it’s better to start building the software and deliver results.
Customer collaboration over contract negotiation
Instead of spending weeks or months discussing the contract, ensuring compliance and rules if we deviate, it’s better to collaborate. Collaborate to build great software and to build a great relationship.
Responding to change over following a plan
Instead of following the plan as stipulated in the contract and building ‘everything that needs to be built’, we iterate. We build a version of the software, inspect the results for the users and continue development based on what we found.
Fixed price, agile development
The big challenge with moving to agile contracts is: most customers want a fixed price. This means that sales people prefer to sell fixed price, so they can meet their client’s demand. To find a middle ground, many providers agree on a fixed price, while their teams work agile. One way to go about this, is to ‘hide it’, as Allan Kelley describes on infoQ
The simplest, least disruptive, way of using Agile within a delivery contract is just to hide it. Don’t tell the customer you are working any differently to normal. Estimate and plan the work as you would normally, sign a perfectly normal contract, then use Agile techniques to improve delivery.
As I’m a big fan of ‘openness‘, I believe hiding it isn’t a option. Our goal is to build a partnership and those never start with hiding stuff. Relationships are built on trust and transparency. On top of that, if only one partner buys into agile while the other doesn’t, agile won’t succeed as it could.
Most of the agile projects that fail do so because there is a misunderstanding of agile – usually on the customer side – and what that means for the working culture, project governance and the extent and involvement of customer resources.
This means that in order for agile to work, we need to create buy-in from both sides. Everyone involved needs to be educated – so we create the right culture. Fixed price contracts in my experience lead to complacency at the customer side. Because ‘everything that needs to be built’ is nailed down in a tight contract, the customer can sit back, relax and enjoy the ride. But agile is about teamwork and the product owner on customer side has a crucial role in the team. Therefore, to start with a fixed contract misses the goal.
I believe the premises on which to build an agile contract can be kept simple. The ingredients we need are:
A. A price per iteration
B. A clear definition of done (value)
C. An exit clause
I like the way Allan Kelly
describes the ‘rolling contract’:
If we wish to keep customers involved, then we need a mechanism to involve them and continually ask them to recommit to the work. This is where rolling contracts have a part to play. Rather than agree to a large piece of “all-or-nothing” work, the customer and supplier put in place a framework agreement for a series of short development mini-projects, call them episodes or iterations if you prefer. The contract probably has some overall goal but doesn’t contain a shopping list of specific features and functions. The discovery of needs is part of the work itself.
With each delivery the customer pays the supplier and has a choice: continue to the next iteration or halt here. The emphasis is put on the supplier to a) deliver something that adds value and works, b) demonstrate that there is more worth doing that will add value. If the client cannot see that the value created is greater than the cost they can walk away from the work with that which has been created so far. Equally, if the supplier finds that the client is not cooperating they can walk away too.
First and most important of all, we avoid describing ‘everything that needs to be built’. In practical terms, the question that comes up here is ‘if we don’t specify everything, how do we know the size of the project?’. The most simple solution is to do a ‘sprint 0’: the full team (PO, SM and dev team) sits together and on a high level discusses and describes the user stories. During this session, the team will get a good understanding of the needs of the customer. Based on this understanding, a rough estimate can be assigned to each user story. The total weight becomes the scope of the project
. We could fix that scope in the contract for budgeting purposes. As we can fix scope, price or time, there are some other variants, nicely described in this article by Debbie Madden
Next, we need to define what ‘unit’ the customer pays for and under what circumstances parties can deviate from this. In the ideal world, this ‘unit’ is ‘value delivered‘ (outcomes, not input). Although possible, it is very hard to get to a clear definition of this value. Therefore, the simple solution is to use ‘input’. This is based on time and material: each sprint has a price, based on the team size for the sprint.
If we want to get closer to ‘value delivered’, we could add a bonus/malus to this. We could define that each sprint, the team commits to delivering ‘x story points according to the definition of done’. At the end of the sprint, we look at how many points have been completed (y). The customer pays y/x of the sprint price. The problem here is that we could get discussions about the reasons for (not) completing user stories; the source could be either of the partners. This gets us back to the ‘extra work’ discussion famous in traditional contracts, that we’d like to avoid.
The last element we need is an exit clause. If the contract would be completely ‘time and material’, the supplier may become complacent as they can invoice each sprint without an incentive to deliver value. To create a middle ground, the contract can stipulate that the customer can end the project after each sprint. If the supplier does not deliver the value expected by the customer, the customer can just stop the contract. This gives an incentive to the provider to keep delivering value. And it gives the customer an instrument to ensure they get what they expect. To soften the impact, we could add 2 things:
A. There’s a cancellation period or fee, for example 1 sprint. This allows the provider to find a new project for the team. It also stimulates a customer to cancel only for valid reasons as it comes with a cost
B. A ‘value delivered’ or ‘overall satisfaction’ metric. The partners can measure the overall level of satisfaction from both sides with the collaboration and/or the value delivered. If we do this on a scale of 1-10, we could stipulate that the customer can only cancel if this metric went below 5 for 2 or more sprints. This ensures that the customer cannot cancel ‘out of the blue’ for reasons beyond the control of the provider.
If we truly want our projects to run in an agile way, we need to abandon traditional contracts with fixed prices. The most simple basis for an agile contract is to make it incremental. The scope of the project can be based on a ‘sprint 0 workshop’. The contract stipulates a price per sprint, based on the team members required and their hourly rates. We clearly define what value means, based on the definition of done. And we describe an ‘exit’ clause which gives each partner an ‘out’. Using these ingredients, we create a contract that has ‘co-creation of value’ as its main objective.