As our team grows and our agile practices deepen, I spend an increasing amount of my time reviewing and negotiating contracts for agile software development.
I believe agile development projects justify a fundamental rethink and extension of the core terms of a contract for services.
Ultimately, successful projects are born from transparency, trust and collaboration between people. Agile contract negotiation can and should trouble itself with establishing the high level operational process and delivery frameworks required for those people to deliver successful projects.
Contracts can be viewed as simple expressions of very human hopes and fears, expressed through the offer of reward and backed up by the threat of punishment. It’s particularly easy for contractual negotiations to focus on the fear and punishment side. Yet, at the time of contracting, almost anyone will assure you their main goal in partying-up is to deliver a successful project. Why then, don’t we spend more time thinking about what it takes to deliver success, and less about how to deal with failures?
We are often asked to work under a traditional “Contract for Services” model, particularly one that “The Lawyers” are already comfortable with.
In all honesty, it can pretty much get the job done. With a little nip-tuck these contracts can even look agile on top (although often there is a “waterfall” heart beating just under the surface). Yet, falling back on a more traditional contractual model fails to capture many of the commercial benefits of agile execution (for both client and supplier). It also short-circuits what could be a valuable discussion through which the contracting parties establish , in the context of their unique and specific needs, how they will collaborate to deliver a successful project.
I don’t want to beat up on “The Lawyers” too badly; the world of legal practice is a tricky one. Lawyers by training (and duty) spend much of their time focusing on protecting their client and the rest digging clients out of holes. This can lead to a disproportionate focus on promises, obligations, processes and penalties for resolving breakdowns of trust between contracting parties. Relatively less time is spent on how to maximise commercial benefit to the client.
When negotiating contracts it’s not unusual for significant time to be dedicated to such exciting areas as:
- liability and limitations;
- the extent of indemnifications;
- representations; and
- warranties
It can all too easily become a story about risk allocation and management and the dangers of project failure.
The beautiful thing about agile delivery is that through its very design, the process should incrementally reduce risk and exposure on both sides of the contract. Negotiating a truly agile contract should let us move far closer to the elusive win:win paradigm. We can and should worry less about liability and under delivery, about certainty of deliverables and price upfront or about termination and resource planning. The agile process, with its recurring opportunities for feedback, examination and course correction, fundamentally changes the commercial dynamics and risks. Our experience suggests that client-side confidence generally builds as the delivery relationship becomes established. Practically speaking, that means how we work, price and communicate evolves over time.
The negotiation of an agile software-delivery contract certainly still involves careful and conscious consideration of the promises being made by each party and the obligations flowing from them – if only because delivery failure challenges trust and transparency between parties and undermines the functional relationships we’re reliant on. Delivery failure greatly increases the chance of moral outrage guiding us down the unpleasant path toward contractual dispute.
Perhaps the trickiest thing is that the success of agile delivery does not rest solely on the supplier. A standard Contract for Services typically doesn’t provide for this level of mutuality and interdependence of parties, and it is difficult to retrofit.
Our clients must be an integral part of the development team, empowered to set requirements and priorities and to regularly assess and provide feedback on software as we deliver it. Success depends on the client being ready and resourced to fill this role. If it becomes apparent during contract negotiation that this isn’t the case, no amount of contractual clarity will fix the issue; it’s safest to walk away.
At times, potential clients have a team who are experienced in agile delivery.
On other occasions we may have to guide or coach client teams to grow into their roles. Initial contract negotiation is the perfect moment to assess and respond to this readiness (both at an organisational and operational level), to set clear expectations, ensuring the client appreciates the extent of their contribution, and how important it is.
Ultimately I’m of the view that the most creative and meaningful result of our contract negotiation is establishing (together with our client) a structure for operational process and delivery that is specific to that client/project. In practice, establishing this often takes the form of a schedule appended to the main terms of contract. It is where we set out such matters as:
- How we propose to implement an agile methodology including who will fulfil which roles;
- How to ensure continuous and effective lines of communication (and escalation);
- How to retain flexibility to capture opportunities for learning and change to ensure we actually build the right thing;
- How to ensure adequate resourcing;
- How to balance the inevitable tension between backlog and budget;
- Mutual obligations and expectations around when work will be tested, accepted, deployed and, ultimately, “done”
We aim to build long-term client relationships, based on successful delivery. We know that each project (or phase of a project), each delivery team (and the roles and skills of the individuals within it) will be different. We also know, that even if all else remained the same, those teams and individuals will grow and develop over time. Fundamentally, one size cannot fit all. We need to respond to that by expressly permitting the balance of roles and responsibilities at a project execution level to evolve over time.
Agile contract negotiation should be an open invitation to rethink our definition of success. Rather than negotiating to deliver a contract, I hope to continue a journey toward contracts that support the building of collaboration, transparency, and trust for successful delivery.
Banner image: Photo by cottonbro studio
