Next week, it's time to try to negotiate a contract with one of our customers. We have already worked with this customer already for several months without one. It is entirely possible that we will continue working without a contract after the meeting.
A great amount of trust is needed when working in a contractless state. The process is very simple: The client requests our work, we do the work, we send the bill, they pay it. But the customer needs to trust that we will be there to help them, that we will do high quality work and that we will not overcharge them. We need to trust that the customer won't abuse us and we need to trust them to pay the bills. It takes time to create trust like this, and it can easily be lost. Yet, curiously, a contractless state is neither an improbable result nor is it a huge problem for us and our customers. In fact, approximately 50% of our monthly revenue comes from customers who we don't have a contract with.
While "Customer collaboration over contract negotiation" is one of the values of the agile manifesto, having no contract at all is a somewhat extreme situation to be in. What if two customers are having a crisis simultaneously? Who gets the most attention? How much convenience will we sacrifice when planning vacations if we have no obligations to provide any response times? How can we plan our revenue stream and resourcing if we have no agreement on the work needed? There are several good reasons to have a contract, so why do we so often end up working without one?
Every project is different, but in general the sequence of events goes something like this: initially, the delivery project is negotiated and what happens after production deployment does not get much attention. It is something that can be negotiated later on, as long as there is a promise that post-production support will be available. Then, after the always hectic deployment, the customer cuts down investment, and the majority of the team can no longer stay with the project. If the development bandwidth gets constricted enough, we reach the moment when it makes sense for Lifecycle Management to take over.
Negotiating the terms of post-production development takes its time. Yet, some changes or new improvements need to be done ASAP, so we usually end up doing them before a contract is agreed on. There is initial trust in place, carried over from the development project. And the longer the contract negotiations take, the more trust gets built up from our work and the more the contract starts to look like a detriment to the current situation. We have now created a situation where the development goes on, and agreeing on a contract has become both unlikely and even to some extent unnecessary.
What makes finding a good contract model for software maintenance so difficult? There are several reasons for this, but at least for us, the most important ones are the service level agreement (SLA) and other contractual issues that involve sanctions.
The purpose of sanctions is to affect the behaviour of the participants in a contract. The unintended side-effect is that unless the sanctions are negligible, they introduce so much risk in the business that avoiding the sanctions becomes the primary driver in any future work. This overrides generally beneficial values like collaboration and efficiency, as the risk becomes factored into work estimates and prices. The ability of a team to be agile erodes when all actions need to be planned from the perspective of not getting hit by a big stick.
A good agile maintenance contract should facilitate, not dictate. It should set the stage for co-operation, define goals and trust the participants on both sides to find the best route to reach the goals. It should secure both the customer and the vendor against disasters but avoid obsessing over smaller inconveniences. Applying contractual sticks or carrots endangers co-operation and should be avoided whenever possible, preferring more subtle guidance.
Is a contract necessary for agile maintenance? The evaluation of the need is a complex function of trust, corporate policies, pricing and consequences of a major failure in service availability. Some of our cases do well without a contract and neither side wants one. Some of our cases have a good contract that facilitates the work. With some cases we would like to find a contract but are not able to agree on one that wouldn't hurt the status quo, so we continue without one.
This is the third installment in our series covering an experimental agile maintenance concept at Futurice. Previous installments: Re-inventing custom software maintenance by Teemu. Selling a concept for agile maintenance by Rauli.