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.
What is agile?
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).
Negotiating an agile deal
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.
Summary
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.
Nathan Evans is a Senior Associate in the London office of
Norton Rose Fulbright LLP.
