I need software and I am about to hire a firm to build it for me. How do I write a contract that protects the two parties’ interests?

Scrum turned 21 last year, the Agile Manifesto is 16 and yet, most of the contracts we sign today are negotiated tightly with a well-defined scope, price and end date. If you are among the lucky ones, your management has been somehow enlightened and has the courage to be vague with the scope. In a way, this forces the stakeholders and the team to collaborate closely to achieve some results. Although this is not perfect, it’s a good try to modify the conventional fix scope,budget and timing contracts. If the customer needs to do a 180 degrees, you still need to have some change management that will negotiate the price of any change—not ideal.

What really spikes my curiosity in this big question, is the unsaid and all the assumptions we are making.

Why are we writing contracts in the first place? Because we want to make sure we get what we want and we can legally sue the other party if we don’t. We want to make sure to get paid properly or we can legally sue the other party. We are legally protecting ourselves, both ways—Very good.

To help us writing these contracts, we have identified the elements at risks that are measurable and we want to clarify them as soon as possible, before starting to work on it. With this mindset, an early start may translate into waste of time. Therefore, we go head first detailing the Scope, the Budget, the Schedule. Nowadays, some folks will even think about the Quality of the product, ironically not as easy to measure. (Think of an awkward user experience for example)

Nevertheless, I think we are protecting the wrong constraints. Years of experience taught us that the Scope can be changed, the Technology can be unpredictable and also the People can have an impact too!

Instead, why don’t we protect “how” do we work together, both parties, in order to achieve the best result. This is exactly what the Agile Manifesto expresses.

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Fortunately for me, I am not a lawyer! That’s why this is not a white paper on how to make your contracts more Agile Manifesto-friendly! I can only imagine how hard the “collaboration” will be to measure and how hard it’ll be to prove in case of dispute.

Others were also curious and they were kind enough to share their ideas. Here are a couple of good links to consider:

  1. http://www.agilecontracts.org/
  2. https://www.twobirds.com/en/sectors/technology-and-communications/software-and-services/contracting-for-agile-software-development-projects
  3. https://www.linkedin.com/pulse/top-10-tips-agile-outsourcing-lorenz-cheung