It has been rather too long between this post and the last – consequence of client commitments, apologies.
Last post I looked at the second line of the Agile Manifesto, considering what is suitable documentation standards in Agile Delivery, this time I’ll look at the third line.
Customer collaboration over contract negotiation
So just how much contract negotiation do we need, and taking a step back what really is a contract?
I suggest that a contract is an agreement that specifies the details of the consequences for failure.
Agreements are essential for group delivery, it is what enables one individual or group to operate independently from another. There is usually some element of collective benefit, either both sides are working towards a common goal or there is a transaction attached.
Good agreements run on trust, each party has respect and trust in the other to deliver as expected, and therefore what is really at stake for failure is that trust, which is often the most important powerful thing we have. Agreeing to your spouse to be home for 19:00 is a good example. Within Agile delivery you can express Sprint commitments , WIP limits and acceptance criteria as agreements.
Agreement is based on trust and respect, a contract goes further than these honour based agreements, extending this to provide consequence to failing to comply with the agreement.
Firstly contract can mean different things to different people in different contexts. I currently find myself in a supplier /client type relationship where the contracts are legal documents and stipulate costs and disclaimers and liabilities and the like, at other times I have been working in house in which case the contracts are more intimate and are reflections of commitments between departments or even people.
There are many articles on commercial Agile contract structure / writing and I am not going to tackle that subject here – save it for another day. In summary I’d say keep it T&M and keep your contracts as short and easy to renew as possible.
It isn’t contracts that the Manifesto makes reference to, but the negotiation. Negotiation is an attempt to reach an agreement that is favourable to you. I’d argue that the best (more realistic) contracts are those that you’d be willing to sign up to either side of.
Agile delivery is all about safe to fail experiments, having the freedom and flexibility to try something and then take the learning, we wont be right all the time but the really important part is the consequence of failure is not catastrophic.
Excessive negotiation implies that you are looking to tip the balance of in your favour – it is less of a partnership now and the trust is being eroded. In a one sided contract either then likelihood or consequence of failure on one side is greater than the other – and probably known to be so. Risk is not equally shared. This is not limited to legal contracts, a senior manager in house can make it clear the consequences of failure to deliver a sprint in terms of performance appraisals, future projects or weekend working.
The premise of the manifesto statement is to put the interests of the project delivery ahead of those relating to an individual or a supplier; an unbalanced contract will encourage behaviours of self-protection, as opposed to collaborative, delivery facing behaviour. Teams will start to look to identify where they can cut quality without being noticed, or the scope details of feature items will be expanded – in addition to other nefarious activities.
The sad truth is that in both scenarios, everyone loses. Either the project fails or the client has over paid and is unlikely to offer repeat business.
So we value contract negotiation, in that it gives us a framework to deliver, it makes clear the agreements and a fair set of consequences, negotiation to a point where you’d no longer sign the other half of the contract… now then I believe it to be counter productive to delivery.
The ultimate contract is a partnership, and the ultimate consequence is loss of trust.