The art of the agile deal

This article was originally published on the Society for Computers and Law website (www.scl.org) in May 2018.

Whether we lawyers are advising on a platform integration, a generic IT framework, or a true design and build project, at some early point in structuring the deal, we need to ask: is software being developed using agile? Unless market norms have seriously changed between the time of writing and publication of this article, the answer will in the majority of instances be ‘yes’. Given that is where the market is, all technology lawyers need to know their way around agile, not only to protect their client’s legal and commercial interests, but also in order to build a common understanding of what the services are, what the expected outcome from the services is, and to give the project its best chances of success. For, as we all know, too many IT projects end up in dispute and a great many of these disputes could possibly have been avoided had the parties taken a bit more time to test each other’s understanding of the deal.

In this article, I will aim to answer the following question:

How do we help our clients to resolve the apparently irreconcilable needs of the contracting parties (i.e., the supplier’s need for flexibility, and the customer’s need for contractual, cost, and delivery certainty)?

To do this, I will share some of the experience I have gained by negotiating agile deals and provide (hopefully!) some useful and practical insights for junior IT lawyers and seasoned lawyers looking to expand their practices into software development or to understand the topic a little better. 

Before agile, software developers (particularly in the larger IT providers) tended to adopt a linear method of developing software whereby the customer (often with the help of SMEs such as business analysts) created a detailed specification of its requirements against which the supplier would build the software in cascading phases, often as follows:

Requirements > Design > Build > Integrate > Test > Support and Maintain

Pricing for the whole project was typically set at the outset, subject only to scope change and, given the cascading phases through which the project moved, this process is commonly known as ‘waterfall’.

In contrast, agile builds follow a less documented process whereby the customer’s requirements for the software, rather than being known upfront, are explored and updated as the project progresses through iterative development cycles.  

There is no market standard agile methodology. Commonly (although perhaps wrongly) agile is viewed as the antithesis of waterfall and is predicated on the 12 principles set out in the agile manifesto. 

Through the adoption of nimble, collaborative, and incremental development phases, agile’s objective is to result in the fast creation of working and user-focused software. 

There are several loosely-competing models for agile delivery (eg, SCRUM, DevOps, Kanban and Lean SD), and most deals adopt a supplier-specific variant of a process known as ‘scrum’. 

In a scrum, teams of developers who are:

• managed by a ‘scrum master’ - the supplier’s representative who is responsible for overseeing the development team and managing the supplier’s responsibilities; and
• instructed by a ‘product owner’ - the customer’s representative who is responsible for instructing the supplier, developing the customer’s requirements, and prioritising items to be developed.

Develop software over a series of time-boxed development cycles known as ‘sprints’. At the end of each sprint (which are commonly two weeks in length), the supplier should be delivering potentially shippable software.

Using scrum techniques, the scrum master will (sometimes) organise its development team into pods, chair daily planning (‘stand-up’) meetings, and oversee each sprint cycle. The process is then repeated until the ‘product backlog’ is complete. The product backlog commonly comprises a list of ‘user stories’ (ie short descriptions of software features from the perspective of the end-user). 

For many agile practitioners (that is, the non-lawyers in the room), agile is more of a state of mind than a process capable of being documented and, therefore, they may at first see little need for lawyers to comment on what agile is or how agile works. Their view, understandably, is that the most important thing is to create working software. However, because using agile creates a catalogue of legal and commercial risks, lawyers will need to be involved. For example:

• the methodology itself must be discussed, with consideration given to how it impacts upon legal and commercial risk; and
• outputs must be mutually agreed and documented. 

No doubt with the best intentions, some agile practitioners will try to sell ‘partnership’, ‘collaborative working’, and the promise of a dispute-free development through agile. However, a cursory look at De Beers UK Ltd v Atos Origin IT Services UK Ltd [2010] EWHC 3276 (TCC) serves as a reminder that agile must be written in contract, and it must be done so with care.

And, with that in mind, how then can we add value, commercial benefit, and contractual certainty to the deal?

Get project documentation

Pointing to documentation in a well-managed waterfall build is a relatively straightforward affair. There would, for example, be design and technical architecture specifications, functional specifications, and detailed acceptance criteria agreed at the outset or otherwise written as part of the development. 

By contrast, in many (although not all) agile developments, preparatory design documents will simply not exist. In fact, agile purists argue that preparatory design documents are outmoded and have been replaced with self-documenting code. 

Working software at delivery is great, but it almost always breaks at some point, and that is why customers buy support. Accordingly, customers ought to insist on the creation of a single repository of technical and functional documentation (for example, detailed user documentation, support guidelines, data designs, interface designs, and technical architecture etc), even if creating this documentation requires additional effort and cost. 

This is particularly important if the developer is not likely to be later asked to support and maintain the software by, for example, using an ITIL-based (the Information Technology Infrastructure Library) support model. This may be because support is to be delivered in-house or because the developer in question does not offer ITIL and prefers instead to limit its support obligations to a tier 4 level of support (ie technical support and incident resolution services provided by the manufacturer of software - often when a third-party support provider is unable to resolve an issue without reference to the original coder). Elite software houses may well take this approach. 

Not to document the software may severely limit the customer’s ability to maintain the software (whether by itself or by using a third party) and does not lend itself to a fully transportable solution. 

Additionally, the creation of documentation will go a long way towards building demonstrable and meaningful criteria against which the software may be tested, improving contractual certainty and the customer’s ability to trigger break/fix warranties for defects.

Agree a description of the chosen methodology

You can, whether acting for a customer or a supplier, spend a great deal of time crafting an ‘agile’ template, perhaps based on the assumption that the supplier will be adopting a variant of an agile methodology known as scrum. While the supplier may indeed be using a variant of scrum, do not be surprised if the supplier receives your carefully drafted methodology with barely concealed antipathy (particularly if you are acting for the customer).

To bat the proposed methodology away, many suppliers may tell you, ‘this has been drafted by someone who has never actually worked in software development’. To avoid this kind of situation and to manage client expectations, it is helpful when acting for the customer to prepare the customer for this response, and to explain upfront what it is you are trying to accomplish (which will be a final methodology which, although tailored to reflect the supplier’s normal working practices, includes some of the risk-mitigating mechanisms explored below).

It is unusual to agree a development methodology which completely resembles your first draft and that may be no bad thing. The supplier could (and often does) propose efficient ways of working which suit the composition of its own team. Having this discussion allows the customer to explore and understand the supplier’s specific working practices, and to satisfy itself that it is appointing the right partner. 

Furthermore, as much as we may counsel against it, the reality on the ground will be that the contract may well sit in a drawer for the life of the project while the parties get on with the build. Better then, that the contract actually does reflect what the supplier’s development teams have been trained and internally mandated to do.

Given such a state of affairs, might it be easier and more pragmatic simply to ask the supplier for a copy of their methodology and just work from there? This can work, but many suppliers do not have their ways of working documented (‘we value working software over comprehensive documentation’) and presenting a first draft allows the customer to put the supplier on notice that the contract will need to contain certain checks and balances in order to satisfy its risk/finance function. 

Many CFOs within customers will take a fair bit of convincing before they get fully comfortable with using agile in the first place, let alone signing off a project which, at its inception, carries little in the way of fixed scope, tangible and defined outputs, or (in most cases) price certainty. Working with a supplier to document its methodology and to incorporate within it in various checks and balances can (together with other risk mitigations discussed below) help customers and their key stakeholders obtain a degree of comfort in relation to the process. 

Checks and balances

There are a few well-trodden checks and balances which help bring customer stakeholders along for the journey. For example:

Velocity

When a supplier talks about ‘velocity’, it is normally referring to the completion rate of listed items in the product backlog over each sprint. For example, one might expect that five items are completed during each and every sprint, or that a certain amount of effort (so-called ‘story points’) is to be expended. A story point is commonly an estimate of the supplier resource required to deliver a listed item in the product backlog, usually represented by defined units (for example, one story point may represent five hours of an engineer’s time). The method for calculating story points tends to vary between suppliers.

Naturally, velocity is subject to certain variables, particularly if the backlog includes items that carry high complexity or associated effort. However, taking steps to agree a minimum average velocity over a fixed number of sprints can help to ensure that project milestones are hit, given that the supplier will not be permitted to take its foot off the pedal. Additionally, once a ‘minimum velocity’ is agreed, this can be tied to enhanced supervision and/or termination mechanisms.  

Viability

In order to achieve some measure of outcome certainty against cost, if a baseline product backlog is available at the outset or, as is usually the case, can be created as part of a discovery phase then the customer ought to take steps to agree which items in the backlog must be delivered in order for the supplier to produce what is commonly referred to as the ‘minimum viable product’ or ‘MVP’. 

Such items can be regarded as ‘mandatory’ user stories (ie user stories which must be delivered by the end of the project) and the contract can commit the supplier to delivering them, ideally at a fixed or capped price. 

If a fixed or capped price is achieved in relation to the MVP, you will need to consider including a bespoke change mechanism designed to manage net increases and/or net decreases to the effort required to deliver the MVP, particularly where new mandatory user stories are added or removed by the customer’s product owner. Doing this gives the supplier some comfort that it will be able to recover its costs arising from scope change but also allows the customer to assert a measure of control over how such costs will be calculated. 

Testing

Test clauses are among the most critical and yet over-looked provisions in any software development contract. 

Precedent test schedules (taken from, say, an outsourcing or waterfall deal) typically provide that all ‘deliverables’ will be subject to ‘acceptance testing’ and at some point a ‘certificate’ will be issued. They are not appropriate in the context of an agile deal. This is because, in an agile deal, it is unlikely that individual backlog items will be tested by the customer (and to do so in isolation from the overall solution is fairly meaningless and will also disrupt the flow of the sprints). 

Instead, the contract should provide that the supplier will carry out continuous and iterative testing in-flight, and re-insert failed items back into the backlog (being careful, though, to ensure that the customer is not paying for the correction of the supplier’s errors). 

At fixed checkpoints, however, customer testing (end-user, security, pen testing, end-to-end - whatever is necessary depending on the product) will be needed (particularly if any portion of the charges has been held back pending successful go-live) and the contract needs to make that clear. 

For example, the parties may agree that certain versions or releases must be tested in order for any charge hold-backs to be released or for project gateways to be passed. This will help to improve the likelihood that go-live testing and cut-over into steady state is achieved with the minimum of fuss, and gives the customer a mechanism under which it can raise delivery concerns or dispute invoices. 

On a practical level, though, the customer’s aim should be to define what ‘working software’ looks like, commit the supplier to deliver working software at the end of each sprint (which it should be doing anyway), and appoint a suitably skilled and experienced product owner to oversee the development and, ideally, to sit within the supplier’s own team. Traditional break/fix warranties in respect of defects in the final release remain appropriate and should be included.

Price

If you are fortunate enough to have been instructed prior to the selection of the supplier, or if you are acting for a supplier and wish to ensure a competitive bid, it is important to tackle the commercial model at the outset. 

The biggest commercial risk for a customer will be to appoint a supplier who simply acts as an augmented resource or on a pure consultancy basis for open-ended time and materials charges. This gives the customer little control over spend and gives little comfort to customer CFOs.  It is therefore definitely worth exploring:

• fixed or variable fees for the MVP; and
• capped time and materials rates for the project or for each sprint or series of sprints.

Agile should not be used as an excuse to off-set or remove all delivery risk from the supplier. Even prior to agile, software could be developed in an iterative and collaborative fashion. If your client has specific requirements that must be met, then of course these should be provided for contractually. Push-back to the effect that to deliver these requirements would not be ‘in the spirit of agile’ is not a good enough reason. Agile is ‘in trend’, but if your client does not think it is right for their project then they should say so at the outset. However, in making such decisions, a well-advised client will bear in mind that that agile does not need to operate as if it were the antithesis of the stark risk allocations inherent in a waterfall project. A well-brokered middle ground is entirely possible.