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  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:
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.
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.
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.
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.