Agile value: 3 – Customer collaboration

The Agile Manifesto describes four key Agile values which are expressed in pairs and each covered in separate articles:

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

The third Agile value as with the others is challenging standard beliefs.  And like others, this statement causes confusion when first read.  Traditional approaches and Scientific Management say that success comes from tough and aggressive negotiation.  Get a good deal, deliver on that deal and you will be successful.  Let’s consider the alternative that this Agile value means.

Customer collaboration over contract negotiation

Manifesto for Agile Software Development

We’ve learned that it is important not to start from the idea that the item on the right is “bad”.  Indeed the right hand side tends to be the “must have” item that you need for “table stakes”.  That seems to be the case here.  You clearly need to be able to agree contractual terms to be clear what you have to deliver and how you will make money from delivering it.

Complicated or complex?

The Agile manifesto is saying that this structure is important. But that once you have this structure in place, doing more of the same will not make you better.  Sticking more rigorously to the terms of a contract and arguing more about the interpretation will not make your business grow.  This comes back to the difference between complicated and complex work.

If the work is complicated, it can be exactly defined.  In the same way as we can plan and specify it technically, we can also define it legally.  We can be exactly clear about every element delivered, what it will look like and how it will work.  The contract in many ways reflects the planning.

However, if the work is complex, we have seen we cannot write a detailed plan.  We expect learning and change over the development and inherently due to that development. 

We cannot control that by increasing plan detail.  In the same way we cannot control it by increasing contract detail.  

Delivering exactly as the contract wording says will not make the software add more value for the customer.  If our original thinking is wrong, and that thinking becomes a contractual constraint, then our solution will inevitably be wrong.  This is an outcome which we often see in contract-driven projects.

This may seem idealistic, but with care it is possible to design flexibility into contracts to allow both vendor and customer to succeed.  In a past organization where I worked, the key factor here was royalty payments.  The customer pays royalties based on successful use of the product.  Similar models are often adopted with SaaS (Software as a Service) solutions which pay according to amount of value the product creates for the customer. 

This becomes a win-win solution.  The more the customer succeeds, the more the vendor succeeds.  This shared success incentivises the vendor to collaborate beyond the strict terms of the contract, to enable customer success.  This collaborative success then in turn enables vendor success. The result is a true partnership model.

In Agile development, the vendor and customer become partners.