Callum Sinclair is a Partner in the Intellectual Property and Technology team in DLA Piper’s Scottish practice, and has worked in the field of ICT law for over eleven years. His experience ranges from major ICT outsource programmes and business-critical systems procurements worth over £1 billion, to smaller innovative software development projects using agile development methodologies.


Agile software development is very much “in vogue” at the moment.  For those of you unaware of what agile is, the Wikipedia definition ( is as good as any:

“Agile software development is a group of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionary development and delivery, a time-boxed iterative approach, and encourages rapid and flexible response to change. It is a conceptual framework that promotes foreseen interactions throughout the development cycle”.

Agile software methodologies are here to stay, yet some legal practitioners may still feel they are entering unchartered waters. So how can we best bridge the knowledge gap and be agile lawyers?

As technology lawyers our job is obviously 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 that they can make informed decisions.

But we are also commercial lawyers. That means it is critical that we understand the context in which we are asked to draft and negotiate contracts 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 agile 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. I would even venture, 11 years on from publication of the Agile Manifesto, that the past couple of years have seen a 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, lawyers often see only lack of certainty around price, timescales and ultimate deliverables. We may also be concerned about a series of “agreements to agree” (e.g. deferring decisions about scope, acceptance criteria and budget for a sprint until just prior to that sprint’s commencement) – as we know, 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.

Key to success is a close working relationship between lawyer and client. Once the case for agile has been clearly made, the following checklist can help ensure best practice:

1. Read up and develop a good understanding of what agile development is and what benefits it can deliver at an early stage in the process.  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 may help to alleviate your concerns about early termination and liability provisions.

2. Consider the relative merits and risks of agile vs. 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. When advising a customer, encourage them to ensure that business case documentation and requests for proposals are sufficiently flexible to accommodate agile methodologies (assuming point 2 above has not ruled these out). Our advice to support good procurement practice will often involve us advising that proposed contract terms be attached 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 which are 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. Consider limited contractual controls to re-introduce further certainty: Minimum Viable Product definitions, capped overall project costs, and longstop delivery dates are all examples.  Whilst 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 for lawyers to keep up with developments in the industry and stay agile.