How to make IT contracts agile

Agile software methodologies have been around for years, yet many in the legal profession still feel they are entering unchartered waters

Agile software methodologies have been around for years and are here to stay, yet many in the legal profession still feel they are entering unchartered waters. So what can IT professionals do to bridge the gap, and how can they best understand the lawyer's point of view? In short, how can you keep your lawyers agile?

The job of a technology lawyer is to protect clients from undue risk arising from relationships they form in the course of their business, or at least to flag that risk so they can make informed decisions.

But for a commercial lawyer, it is also critical to understand the context in which contracts are drafted and negotiated on behalf of clients. This may appear to be stating the obvious but, in the context of agile software development, it is not happening readily enough. Lack of understanding of agile methodologies among legal professionals, and the resulting lack of contract precedent and "legal" case studies, are slowing down the uptake of agility in big business.

The flexibility, responsiveness to change and other benefits which agile methodologies can deliver if properly implemented, are generally accepted among the technology community. Statistics around relative project success of agile versus more traditional waterfall techniques are also well publicised among IT professionals. In the 11 years since publication of the Agile Manifesto, the past couple of years have seen perhaps the most raised public profile of agile with the likes of the Cabinet Office's "lean and agile" procurement agenda.

However, when presented with (or asked to draft) a contract to embody an agile approach, a lawyer sees lack of certainty around price, timescales and ultimate deliverable. He or she will also be concerned about a series of "agreements to agree" – such as deferring decisions about scope, acceptance criteria and budget for a sprint until just prior to that sprint's commencement - these are generally difficult to enforce at law in the event of dispute. A combination of these factors will unfortunately defeat the risk control systems of most large organisations and militate against the use of agile methodologies.

So as a customer believing in the benefits of agile, or a supplier seeking to sell them, how do you begin to persuade lawyers and senior management that agile is the way to go? Suggestions include:

  1. Ensure there is a basic understanding of what agile development is and what benefits it can deliver at an early stage in the process. Brief crib sheets or case studies may help to illustrate and secure buy-in. Be upfront about the risks, but focus on characteristics of agile which may help to mitigate those risks. For example, agile's focus on a working deliverable at the end of each iteration can help to alleviate lawyers' concerns about early termination and liability provisions.
  2. Consider the relative merits and risks of agile versus waterfall for the proposed project in light of the scale of the project, the culture of the customer organisation, the availability of resource on the customer side and so on. Decide early whether that analysis rules out any specific approach for the project concerned.
  3. As a customer, ensure that business case documentation and requests for proposals (RFPs) are sufficiently flexible to accommodate agile methodologies - assuming point 2 above has not ruled these out. Good procurement practice will generally involve lawyers seeking to attach proposed contract terms to RFP documentation to secure agreement in principle from suppliers, but this can be problematic if those terms assume a waterfall delivery methodology, as many based on existing precedents do. Consider seeking similar comfort by attaching a set of contract principles or dual forms of contract to reflect each approach.
  4. Work with lawyers to consider limited contractual controls to re-introduce further certainty: "Minimum Viable Product" definitions, capped overall project costs, and longstop delivery dates are all examples. While these arguably start to chip away at the flexibility of agile, hybrid models like this can work as long as the trade-off is properly understood.

As agile methodologies continue to gain mainstream acceptability, and organisational cultures begin to adapt to accommodate the possibility, so lawyers will become more familiar and comfortable with agile methods and contract forms. There will no doubt be bumps in the road - a high-profile "agile IT project" failure is inevitable - but this should make it easier in future to keep your lawyers agile.

Callum Sinclair is a partner in the intellectual property and technology team in DLA Piper's Scottish practice.

Read more on Software development tools