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?

1. What is “Agile” and is the whole concept of an “Agile contract” nonsensical?

There are four core Agile values:

1. Individuals and Interactions over Processes and Tools
2. Working Software over Comprehensive Documentation
3. Customer Collaboration over Contract Negotiation, and
4. Responding to Change over Following a Plan

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?

2. Agile’s power is in its flexibility. But Agile projects do have an underlying structure.

There are twelve principles of Agile software:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity–the art of maximizing the amount of work not done–is essential.
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.

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:

• a time and materials contracting model; or
• a fixed price contracting model.

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.

3. Our two choices - time and materials contracts or fixed price contracts

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:

• time and materials contracts, where the supplier provides their people at a fixed daily rate (or hourly or monthly rate), but the supplier does not guarantee in the contract that their people will produce any particular outcome; and
• fixed price contracts, where the supplier only gets paid if (hopefully when) the supplier has achieved specific outcomes.

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):

1. a daily rate for some initial “general consulting” work;
2. then a fixed price for the supplier to produce a detailed design document for the project; and
3. then a fixed price (specified in that design document) to implement the project (e.g. develop software) or to provide other output or outcome specified in the applicable contract documents. The supplier is traditionally paid milestone payments (specified in the design document) after each part of the project is completed by the supplier and accepted by the customer.

4. So does the Agile “customer collaboration over contract negotiation” requirement mean that we can only use time and materials contracts?

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.

5. But isn’t fixed price the opposite of Agile?

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.

6. A fixed price Agile working example

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:

1. The customer pays the supplier a daily rate for some initial “general consulting” work. Pure Agile. Simple.
2. Then the customer pays the supplier a fixed price for the supplier to produce a detailed design document. We still have no detailed specifications so we can follow our Agile process. But the customer and supplier can agree a fee cap and timeline for providing this design document. If we follow rule 4: “Business people and developers must work together daily throughout the project”, then any scope (and pricing) change process should be quick and simple.
3. Then the customer can pay the supplier a fixed price (specified in that design document) to produce the final deliverables specified in the applicable contract documents. The customer can also pay the supplier milestone payments (specified in the design document) when each part of the project is delivered and accepted by the customer. Again, if the customer and business teams follow an Agile process, then changes to the pricing and milestones should be quick and simple.

7. But that’s not a “true” Agile process!

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.