One of the four core Agile values is “customer collaboration over contract negotiation”. So is it possible to negotiate an “Agile contract” or is the whole concept nonsensical?
There are four core Agile values:
- Individuals and Interactions over Processes and Tools
Dave Thomas, one of the original creators of Agile, laments in an article that the term has been subverted by consultants and suppliers to the point where it has become meaningless.
I agree. And yes I am a consultant. And yes I see the irony here. Given that one of the core Agile values is “customer collaboration over contract negotiation”, there is a strong argument that the whole concept of “Agile contracts” is ridiculous. As Dave says in his article:
I haven’t participated in any Agile events, I haven’t affiliated with the Agile Alliance, and I haven’t done any “agile” consultancy. I didn’t attend the 10th anniversary celebrations.
Why? Because I didn’t think that any of these things were in the spirit of the manifesto we produced. Having conferences about agility is not too far removed from having conferences about ballet dancing, and forming an industry group around the four values always struck me as creating a trade union for people who breathe.
And, unfortunately, I think time has proven me right. The word “agile” has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.
But we still need contracts with our suppliers. We still need to lock down the fees, and specify in writing who owns the intellectual property rights in what the supplier produces. So what type of contract should we build if we want the process to be Agile?
There are twelve principles of Agile software:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
If a customer builds an in house team of developers, then we can follow the above process, and avoid contracts completely. But we have two choices if we need to integrate supplier engineers into our team or project:
The core issue is actually whether the customer and the supplier need to agree the specifications for the project in writing up-front, and (if so) how detailed these specifications need to be.
It sometimes seems more complicated than this. But, actually, if customers utilise people (e.g. software developers) who are employees or contractors of the suppliers, then they do so under one of the following two contracting models:
There are only two models. With fixed price projects, the specifications are agreed in writing up front, and with time and materials projects, they are not.
All contracts for the supply of people are a variation, and sometimes a combination, of the above two contracting models. For example, under the traditional waterfall contracting model, a customer might pay a supplier (all under one contract):
I don’t think so. A better question is how detailed do the specifications in our contract documents need to be. An Agile approach calls for these specifications to be as high level as possible to allow the teams to run the project in as flexible a manner as possible.
For example, time and materials contracts are appropriate for really small projects, such as the initial consulting part of the project described above. But the problem with time and materials contracts is that the supplier does not commit to deliver any specified outcome within any specified period of time.
Therefore, signing a time and materials contract limits the amount of time that we need to negotiate specifications (and contracts) up front, but significantly increases the risk that the price, timeline for delivery, and outcome will be nothing like what the customer originally expects.
In other words, if we ask a supplier to implement a multi-million dollar project under a time and materials contract, then we court failure. And a customer would be negligent if it risked running a multi-million or billion dollar toll road or other major infrastructure project as a pure time and materials project.
Again, no, I don’t think so. Let’s look at the fundamental differences between time and materials and fixed price contracts.
For time and materials contracts, at the start of the project, the customer and supplier may estimate the time, and therefore cost, of producing a particular outcome. But if we sign a time and materials contract without taking the time to draft clear specifications (and agree on project timelines, costs, and deadlines), the customer takes all of the risk that this estimate is wrong. Or that the deliverables will be nothing like what the customer originally expected. The customer will then need to pay for the supplier’s additional time, and the supplier is not penalised if the project takes longer than the supplier originally estimated. In fact, if the project is delayed, the supplier makes more money even if this delay is caused by the supplier’s delays or mistakes.
On the other hand, a fixed price contract (for example that requires the supplier to follow a traditional waterfall model) requires the customer and supplier to spend a lot of time up-front developing specifications. This is often the opposite of an Agile process. The negotiation process can be clunky, and any change to the specifications can be a tedious process that ignores the value of principle 11:
The best architectures, requirements, and designs emerge from self-organizing teams.
But the advantage of a fixed price project is that it requires the supplier to commit to a price and timeline.
Let’s go back to our example project. The customer needs both flexibility and for the supplier to have “skin in the game” by committing to specific deliverables and timelines. In other words, we need to agree how Agile principle 12 will work for each project:
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.
So for our example project we can implement an Agile process as follows:
Yes, OK, you’re probably right. But if by “true” Agile, you mean that all projects should be time and materials projects with no specifications agreed up front in writing, and no supplier delivery risk, then there is no chance that sensible customers will agree to this approach for large projects that involve external suppliers. It is not realistic to expect customers to commit to pay suppliers tens of millions of dollars with no specifications agreed upfront, no guarantee that what the customer receives will be anything like what the customer originally wanted, and no guarantee that the price and timeline will be anything like the original supplier “estimate”.
But Agile does not mean no project management or controls. Quite the opposite. An Agile contract is a contract that provides just enough structure (and specifications) to ensure that both the supplier and customer act as the other expects. But an Agile contract should then get out of the way of the individuals who actually deliver what the customer wants. That is the power of Agile principle five:
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
This post originally appeared at iainmclaren.com. These opinions are mine. They are not necessarily those of my employer. Thanks to Josh Morris and Alex Nathan for reviewing drafts of this post.