Agile Contracts are Different – It is Just that Lawyers Don’t Like Them

Matthew Caine Uncategorized 0 Comments

In October 2014, it was explained to me that lawyers don’t like Agile. The person explaining was a lawyer.

He went on to say, “lawyers like to know the processes, the expected results e.g. detailed predictable plans, the cost, the bonus, the malus and more than anything else, they love paperwork. What they don’t like are soft things that are hard to quantify, such as quality and collaboration.”

So it is easy to come to the conclusion that Agile approaches are at odds with contracts. But as we will see, it is possible and in fact many lawyers are now starting to discuss them more (well, they have too!).

Traditional Contracts

Of course, most of us are aware that most contracts are chiseled onto paper and designed to predict all eventual outcomes.

Typically, between a supplier and client, contracts are formulated as: You deliver X by DATE for $X.XX

The supplier then disappears for several months only to appear again a few weeks before the DATE, when it is typically too late, only to claim that the requirements were not clear.

When that happens, you may be thinking that communication must have been poor. After all, if it had been better they would not be in this position. However, they are communicating! So it cannot be communication.

The problem with this relationship is that they are not collaborating. This is the key word.

It is Not About Your Product – It is About Who and How You Work

Back in 2010, I was working for a software vendor. We had secured a massive deal which was worth £12m. The contract covered the software licence, maintenance & support and professional services. This is a huge deal for a company with 44 employees.

Surprisingly however, we were the preferred vendor despite the following:

  • Our product was not the best on the market
  • Our product was not the market leader

How is it possible to win such a massive deal?

We had even gone through the usual procurement processes involving long-listing and short-listing with long RFI and RFP presentations.

So despite the client telling us our product was not the best, they chose us. They wanted to spend the money over three years, with us, to build a better product, our product! Not theirs!

The question I have for you is this: How could we have done this?

It is Not Your Product, It is Your People

The client chose us, because of our people and because of how we worked.

During the selection process they had got to know us and had seen how we worked. We worked in an Agile way that required frequent interaction and collaboration.

In fact, we screwed up once. We kept telling them that we had support for a certain feature that was a must-have for them, and politically highly charged.

In fact, we did not. Our salesman kept trying to avoid the subject. In the end, it came out and the client was really disappointed with us, but most of all with our salesman. Now get this, the client went out of his way to console our salesman, to forgive him. It did however, take a while to recover the trust we had lost.

It once again shows that it is all about people, and Agile practices support it.

Agile Contracts

Let us now focus on Agile contracts. Given that we want to maximize collaboration yet appreciate the equation of the obligations to deliver, namely: You deliver X by DATE for $X.XX

How should our Agile contract look? Let’s take each part in turn:

  1. Fixed Scope (X)
    On paper, Agile practices embrace uncertainty and the emergence of requirements. In reality however, a contract usually contains a certain fixed scope. Usually all “must-haves”. Yet we can use Agile techniques such as story-splitting combined with MoSCoW prioritization to mitigate the risk. For example, an internet banking system “must” support payments. But rather than list “what” the system should do, it should list benefits. E.g. “Allows the user to make domestic payments”. But does it need to support all the detailed functionality, such as “halting a recurring payment for three months”? (which is a could-have or even a won’t).

    So, it is ok to agree a contract when all the high-level requirements are a must-have, because at this stage they are precisely high-level, but they are better defined as benefits, because a benefit can be realized in many ways. And it is exactly when we do this, that we start to get flexibility in the scope.

  2. Fixed Date
    Absolutely, in fact, having a fixed date is one of the benefits of Agile. Think about it for a moment. If your project has 15 sprints, that is 30 weeks. You know exactly when you will deliver. Combine this with MoSCoW and you have predictability [It is only people that use pure scrum that will struggle with this because there is poor predictability in Scrum].

    So, it is ok to agree a contract when there is a fixed date.

  3. For $X.XX
    Agilists often forget that someone is paying for their work. It is usually the customer, and indirectly the customer’s customer. If we know the team, which is our biggest cost, and we know the duration, then we know the cost range. Read that again: We at least know a cost range! No one really wants to know if something is going to cost $56,543.32. Simply stating 52k-59k, most likely around $56k, is good enough for most managers.

What is Special in an Agile Contract?

When we know the why and what, how-much and by-when, traditional contracts are usually done. But with Agile projects, we have to make sure the vendor’s expectations for collaboration are included. This includes such things as

  • Access to the client’s employees, to make sure they are engaged in standups, reviews, planning, refinement and retrospectives.
  • Establishing acceptance rules (who says something is good).
  • Understanding that the solution has to be fit-for-purpose, not perfect.
  • Embracing change, rather than fighting it.

Other things to consider are to:

  • Set the expectation that the vendors employees are to be engaged on site, and vice-versa, such that the client’s staff spend time at the vendor’s offices. The purpose of which is to expose the staff of the two organisations to one another’s culture.
  • Mandate suppliers for a project to have a given video-conferencing hardware setup. A bank in London mandated all suppliers to do this: Without it, no deal.

Procurement, Sales-Pipeline and Agile Processes Match

The procurement and sales processes do match Agile approaches, especially with the DSDM Project Management Framework. Taken simplistically, this could look like:

  • Pre-Project (RFI), This is the initial contact where the vendor can evaluate whether or not to respond. The client has a long-list of potential suppliers and may create a short-list to invite suppliers to respond to an RFP.
  • Feasibility (RFP), where the supplier is short-listed and presentations take place. Certain technical aspects may also be evaluated here.
  • Foundation, this is where the vendor has been selected as the preferred vendor. But there is not enough known about the project to make a concrete offer. So, the vendor and client need to work together (collaborate) to flesh-out the requirements, high-level project plan and understand the sequence that things will be built in.

An Example

I ran three weeks of workshops with the client of the 12m deal. After which, our Product Owners understood what was needed and we could evaluate the efforts required. This took 2 additional weeks. In the end we had spent 5 weeks on the requirements, T-shirt sized them and knew where we needed to invest more time.

Most importantly, we knew where we had to start. In other words, we had a high level plan and together with the client we had formulated the contract’s contents.

We were collaborating right from the start.

Malus and Bonus

This is a common practice that attempts to reward good delivery but punish poor deliver. The only thing that such clauses do, are to replace any feeling of excitement or opportunity with fear (of missing out on a bonus or getting a malus).

In fact, they usually only reward lawyers.

In Summary

Agile projects can be more or less the same as traditional contracts. That means we accept a fixed scope, deadlines and a price (ie the obligations to deliver).

The difference is that we make sure that our collaboration expectations are set. This includes at least the following:

  • Frequent client engagement
  • Embracing change rather than fighting it
  • No bonus or malus clauses

When these are in place, it is unlikely you’ll need to look at the contract ever again.

And oh boy, will that not please the lawyers!


Here are some references available on the internet for you to refer to, search for the text in quotes to start your research:

  • “Norwegian PS-2000” (but I believe you have to buy a license to use it).
  • “Danish K03”

What Next?

Need our Help?

Our half day workshops can help you solving your issue with this topic

Leave a Reply

Your email address will not be published. Required fields are marked *