1. Diamonds and IT – can the two be agile?
Fundamentals of software development in light of De Beers UK Limited v Atos Origin IT Services UK
Limited [2010] EWHC 3276 (TCC)
There are not too many UK legal cases which touch upon agile software development, so to find one
that mentions the concept in any material detail is something of a windfall. De Beers v Atos Origin is
one such example. In developing a large, complex, end-to-end IT system for De Beers to cover its
diamond-management processes, Atos set out with agile principles in mind. The project went awry
almost from the outset, and in trying to steer things back on track, Atos decided to ditch agile and
adopt a waterfall approach. This begs the question "Why?".
Agile & waterfall
It is perhaps worthwhile taking a moment to flag the differences between waterfall and agile
methodologies.
The waterfall methodology will be familiar to most readers who have been involved with software
development to a greater or lesser extent. It was the original, and may still be the most common
method of software development. In essence it is comprised of a series of sequential phases which
start with a big scoping and design effort to establish a customer's business requirements, and agree
a set of architectural and technical specifications to meet those requirements. This design phase is
then followed by actual coding of all relevant software en masse; testing and rework followed by user
acceptance testing (again en masse), and further rework as necessary. All this is to occur to a set
plan and once the business requirements and specifications have been set, potentially in relative
isolation from customers, until code is presented for acceptance.
"Agile" is used to describe a grouping of methodologies which were developed in response to
perceived failings in the waterfall model. They move away from rigid sequential phasing, and instead
focus on a more collaborative and iterative process in which high-level business requirements are first
identified, but then prioritised, refined to a detailed level, coded, built, tested, rectified, re-tested,
accepted, cleansed and integrated in short iterations or "sprints", the outcome of which is intended to
be fully functioning (or at least "potentially shippable") code. SCRUM, originally a Japanese product
manufacturing methodology, is perhaps the most well-known example. The concepts have been
around since at least the mid-nineties, and the "agile" term since at least 2001, but they have arguably
only hit the mainstream in the last five years or so. General legal practice, it may be argued, is still
catching up.
Why did Atos abandon an agile approach?
Atos' approach and reasons for changing to waterfall were as follows:
"[The De Beers project] was originally intended to be developed agile-style. To this end, the team was
organised into BA's [Business analysts] who would define the requirement, and then a pool of dev's
[developers] who would be organised into teams to build elements of the solution incrementally, with
the project beyond the requirements definition set-up SCRUM-style; all supported by an architect and
a few key designer/dev's. This is all very DSDM [dynamic systems development method, a type of
agile methodology] as an approach, and can work fine in the right context, and of course with the right
customer.
It became apparent that this wasn't going to work. This is for several reasons:
© DWF LLP 2011 1

2. The application was much larger than was originally thought, in terms of function points
The application is much more integrated and complex than was originally thought; a huge
end-to-end multi-country workflow, with many of the same business concepts and sub-
processes popping up at many points in the workflow and many "wrinkles" in the detail of the
processes
At contract signature the requirements were high level. Detailed requirements were defined in
January 2008 and signed off in February, and only then were the maintainability and
extensibility requirements expressed in [a particular process requirements document]
apparent.
The customer is demanding, particularly on the technical side, and this did not fit well with an
agile approach to build."
It is probably inappropriate to be overly critical of Atos on the basis of the above extract alone; after
all, it is only one brief snapshot of what was unquestionably a very complicated picture. Furthermore,
this extract is not detailed enough to draw much in the way of a conclusion about how well agile had
been implemented by Atos – although one might be tempted to speculate.
It is, however, interesting to note that the first three bullets all relate back to one fundamental issue:
Atos had not accurately appreciated at the outset what they were getting themselves into. An agile
approach involves requirements being scoped at an initial, accurate, but relatively high level only, with
the real detail being delved into later on. A waterfall approach requires all business requirements to be
scoped in comparatively exhaustive detail. In moving between the two, Atos may have sought more
detail, earlier (something waterfall could help with), but this should not be confused with a desire for
more accurate information, which is fundamental to both.
In any case, it transpires Atos were attempting to shut the stable door after the horse had bolted. They
had already been through two requirements-gathering exercises by the time they wrote the report
from which the above extract comes. They had also signed the development contract. At this stage no
change of methodology would serve as a golden bullet and make up for a fundamental knowledge
deficit, whether in detail or accuracy, or the legal position in which they found themselves.
It is perhaps easier to be sympathetic with Atos wanting to move away from agile because De Beers
were "technically demanding". This phrase is not fully explained in the judgment and many people
would argue agile leads to better, not worse, technical development practices. On one reading, it may
just refer to Atos' lack of technical business and process understanding to which we have already
referred. On another reading, De Beers may have found themselves having to take a leap of faith with
which they were uncomfortable, resulting in increasingly technical demands. Agile methodologies do
require an element of mutual trust, in particular for organisations that are unfamiliar with them or their
potential benefits. That said, if De Beers had to make a leap of faith, Atos had the opportunity at the
project outset to recognise this and generate the required buy-in: if this was lacking, then it needed to
be addressed. Managing it thereafter would just have been another standard project dependency.
Another story of basic errors?
The picture that begins to emerge from looking at Atos' shift from agile to waterfall hints at the wider
reasons why they and De Beers ended up in court. Agile was perhaps the fall-guy for more
fundamental failings, most critical of which was that Atos had leapt into a deal with De Beers, without
looking properly to see where it would land. Some of these failings are outlined below. The quotations
are all taken from the case report.
© DWF LLP 2011 2

3. Resourcing. Atos did not deploy enough time or resources in its otherwise sensible "initiation
and analysis phase" (IAP) before the main contract was signed; one expert who appeared
before the court felt it allowed only half the time that was actually required. This issue was
repeated in a second phase of requirements gathering after the contract had signed.
De Beers' requirements. During the IAP, De Beers found themselves in the position of being
a customer who didn't know what IT system they wanted to buy, at least in part.
"The workshops that were set up to enable Atos' business analysts to identify the
requirements turned out to be unstructured discussion groups in which much time seems to
have been spent by the [De Beers] users in trying to establish what they required as well as
identifying to the Atos business analysts what those requirements were to be".
Sound familiar though? De Beers are hardly the first customer to be in this position.
Pro-activity. De Beers had concerns at the conclusion of the IAP that Atos might not have
grasped the complexity of their processes, but appear (at least on the case transcript) not to
have been pro-active in trying to address the point.
Contracting process. Atos and De Beers proceeded to contract for the delivery of the
relevant system based on the IAP output; however:
"[ATOS] seriously underestimated [the risk that it had not understood De Beer's processes
well enough], a problem that I suspect may have been compounded by an additional factor,
namely that those responsible for the commercial negotiation of the contract did not liaise
very thoroughly with Atos's project manager and business analysts who had been involved in
the IAP."
Such a divorce between the contract and commercial reality is regrettably not uncommon. In
the judge's own words, "it was a failure of internal management for which Atos has no one but
itself to blame".
Availability & Notice:
"There were problems with [De Beers] staff attending workshops and generally being
available to provide information…many of the key people did not have the time to make
themselves available…Atos business analysts did not give enough notice of when they
wanted to see people or wanted them to attend meetings or workshops."
Unrealistic timescales:
"The March/April programme [of development] was never achievable in the first place
because it relied on 100% performance by the members of the Atos team, so that there was
no allowance for sickness or holidays, and because it carried no contingency. These two
factors alone probably meant that it was over optimistic by at least a month…"
Atos' technical practices were lacking in certain areas (to say the least):
"…We have no definition of what system is to be built…In short, what is missing is systems
analysis. This seems to be something of a lost art (within Atos Origin at any rate), and I am at
a loss to understand why. To build a system of this size and complexity it is an essential
activity, and doing it now will undoubtedly pay for itself in the long term and address many
painful risks. But of course, it casts the current plan into outer darkness and will undoubtedly
go down like a bucket of cold sick with [De Beers]."
© DWF LLP 2011 3

4. Unilateral checks. De Beers sprung an independent architectural and code review on Atos
with at most limited notice. Although it was justified objectively, it came like a bolt out of the
blue to Atos and damaged relations between the parties.
Prior experience. De Beers had been bitten once previously on a similar project; should they
have been twice shy? At the very least, the prior experience should have eradicated some of
the behaviours that transpired in dealing with Atos.
"[De Beers] had engaged Accenture to redevelop its integrated stock management systems,
but the project did not go well and after three years it was terminated without achieving most
of its objectives. Accenture complained that the project had gone badly because Accenture's
team had not received sufficient cooperation from the relevant personnel within [De Beers],
and so one of the lessons that came out of this unsuccessful project was that [De Beers]
came to recognise just how unusual the nature of its business was and the difficulty facing
outside consultants who needed to understand it."
Anything to learn legally?
The case largely turned on its own facts and the wording of the relevant contract, so at a technical
legal level, is largely unremarkable. Three points are worthy of note to those interested in the law and
IT though:
Concurrent delay. The Court applied construction law principles by analogy in assessing the
delays that had ensued from both Atos' and De Beers' actions (i.e. where one party's actions
could not be distinguished as the underlying cause of a particular delay):
o Atos was entitled to an extension of time as a result of De Beers' actions. A supplier
has to perform within a reasonable period of time, but by the same token, is entitled
to a reasonable period of time within which to perform;
but
o Atos could not recover damages for any losses it incurred. It would be unjust for a
supplier to recover damages where it would have suffered the same loss as a result
of its own actions.
Scope changes. The Court upheld the accepted view that changes in breadth (i.e. the
addition of new requirements, not contemplated by those originally agreed) are breaches of
contract which unless agreed to, and paid for as contemplated by the relevant contract, are
actionable. By contrast, changes in depth (i.e. adding extra detail to identified requirements
sufficient to enable the build) fall within the contract terms, the risk of which is borne by the
supplier.
The manner of repudiation. Atos was held to have repudiated the contract. Of itself this is
not particularly remarkable. What is more worthy of note, is the stance Atos took (after taking
legal advice):
"What Atos was willing to do was "to complete the project on a time and materials basis at our
own internal standard rates". That is an expression of an intention to complete the work on
different terms, not upon the terms originally agreed…This offer was itself subject, amongst
other things, to [De Beers'] agreement to waive any claim that it may have against Atos in
relation to Atos' delivery to date…There is a very significant difference between being willing
© DWF LLP 2011 4

5. to complete a project, and being willing to fulfil a contract. Atos may have been genuinely
prepared to do the former, on its own terms, but that was itself inconsistent with a willingness
to do the latter."
To the casual observer this seems like a fairly audacious attempt by Atos to shift the contract
onto terms where De Beers took all the risk of delays and cost overruns; presumably banking
on the fact that De Beers would not want to lose a second project. De Beers ultimately called
their bluff. It is questionable how many customers would have the financial strength and
willingness to do likewise.
Conclusions
A software development project can work on a waterfall or an agile basis, but the basics have to be in
place in either scenario in order for the project to succeed. Make sure you have the basics covered.
For example:
For both parties, burying one's head in the sand is not an option; being pro-active to head off
issues is essential. A failing project will still be a failing project unless the causes of failure are
directly addressed, regardless of the methodology adopted. A suitable cross-party
governance regime, including (especially in an agile scenario) close-knit teams is very helpful
in this regard, and will help flag possible issues, but is no substitute for genuine collaboration
on the ground and a mutually constructive, courteous and open attitude.
Appropriate resourcing and planning are key. Timeboxing and other short cuts are
unquestionably necessary on occasion, but beware their potential implications.
From a customer's perspective, it is worth remembering that a set of solid business
requirements is absolutely critical. If a customer does not know what it wants or needs, then
an initial fact-finding consultancy phase is essential to ensure such requirements are
developed, even if time-consuming and potentially costly. The time and costs will be less than
those involved in sorting out a mess later on down the line.
From a supplier's perspective, such an initial fact-finding phase is equally important. If it is
executed properly, it is the foundation on which most, if not all, of the rest of the project sits. If
done badly though, a supplier may reap a whirlwind (as happened to Atos).
Ensure the people responsible for any initial scoping phase and ultimate delivery of a project
are heavily involved in, and have the necessary time to devote to, the proper definition of the
ultimate parameters within which the latter are to act – the contract. It may be painful on
occasion, but it is very necessary.
Obviously, make sure your contract is clear as to who is responsible for delivering what,
when, where and how. From a customers perspective, if you do not have technical expertise
and you are relying on your supplier for certain things – e.g. to build to your requirements – do
not compromise on such fundamentals. Conversely, from a supplier's perspective if you are
required contractually to understand how a customer's business works, make sure you
genuinely have an accurate picture (even at a high level) before committing to a contract. It is
better to do too much work in this regard at the outset, than too little.
Robert Machin (Senior Solicitor)
© DWF LLP 2011 5