Your SlideShare is downloading. ×
Diamonds & It   Agile Software Development In Light Of De Beers V Atos Origin (Dwf 190511)
Diamonds & It   Agile Software Development In Light Of De Beers V Atos Origin (Dwf 190511)
Diamonds & It   Agile Software Development In Light Of De Beers V Atos Origin (Dwf 190511)
Diamonds & It   Agile Software Development In Light Of De Beers V Atos Origin (Dwf 190511)
Diamonds & It   Agile Software Development In Light Of De Beers V Atos Origin (Dwf 190511)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Diamonds & It Agile Software Development In Light Of De Beers V Atos Origin (Dwf 190511)

335

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
335
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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 UKLimited [2010] EWHC 3276 (TCC)There are not too many UK legal cases which touch upon agile software development, so to find onethat mentions the concept in any material detail is something of a windfall. De Beers v Atos Origin isone such example. In developing a large, complex, end-to-end IT system for De Beers to cover itsdiamond-management processes, Atos set out with agile principles in mind. The project went awryalmost from the outset, and in trying to steer things back on track, Atos decided to ditch agile andadopt a waterfall approach. This begs the question "Why?".Agile & waterfallIt is perhaps worthwhile taking a moment to flag the differences between waterfall and agilemethodologies.The waterfall methodology will be familiar to most readers who have been involved with softwaredevelopment to a greater or lesser extent. It was the original, and may still be the most commonmethod of software development. In essence it is comprised of a series of sequential phases whichstart with a big scoping and design effort to establish a customers business requirements, and agreea set of architectural and technical specifications to meet those requirements. This design phase isthen followed by actual coding of all relevant software en masse; testing and rework followed by useracceptance testing (again en masse), and further rework as necessary. All this is to occur to a setplan and once the business requirements and specifications have been set, potentially in relativeisolation from customers, until code is presented for acceptance."Agile" is used to describe a grouping of methodologies which were developed in response toperceived failings in the waterfall model. They move away from rigid sequential phasing, and insteadfocus on a more collaborative and iterative process in which high-level business requirements are firstidentified, 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 tobe fully functioning (or at least "potentially shippable") code. SCRUM, originally a Japanese productmanufacturing methodology, is perhaps the most well-known example. The concepts have beenaround since at least the mid-nineties, and the "agile" term since at least 2001, but they have arguablyonly hit the mainstream in the last five years or so. General legal practice, it may be argued, is stillcatching 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 wasorganised into BAs [Business analysts] who would define the requirement, and then a pool of devs[developers] who would be organised into teams to build elements of the solution incrementally, withthe project beyond the requirements definition set-up SCRUM-style; all supported by an architect anda few key designer/devs. This is all very DSDM [dynamic systems development method, a type ofagile methodology] as an approach, and can work fine in the right context, and of course with the rightcustomer.It became apparent that this wasnt 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; afterall, 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 hadbeen 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 agileapproach involves requirements being scoped at an initial, accurate, but relatively high level only, withthe real detail being delved into later on. A waterfall approach requires all business requirements to bescoped in comparatively exhaustive detail. In moving between the two, Atos may have sought moredetail, earlier (something waterfall could help with), but this should not be confused with a desire formore 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. Theyhad already been through two requirements-gathering exercises by the time they wrote the reportfrom which the above extract comes. They had also signed the development contract. At this stage nochange of methodology would serve as a golden bullet and make up for a fundamental knowledgedeficit, 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 Beerswere "technically demanding". This phrase is not fully explained in the judgment and many peoplewould argue agile leads to better, not worse, technical development practices. On one reading, it mayjust refer to Atos lack of technical business and process understanding to which we have alreadyreferred. On another reading, De Beers may have found themselves having to take a leap of faith withwhich they were uncomfortable, resulting in increasingly technical demands. Agile methodologies dorequire an element of mutual trust, in particular for organisations that are unfamiliar with them or theirpotential benefits. That said, if De Beers had to make a leap of faith, Atos had the opportunity at theproject outset to recognise this and generate the required buy-in: if this was lacking, then it needed tobe 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 widerreasons why they and De Beers ended up in court. Agile was perhaps the fall-guy for morefundamental failings, most critical of which was that Atos had leapt into a deal with De Beers, withoutlooking properly to see where it would land. Some of these failings are outlined below. The quotationsare 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 didnt 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 Beers 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 Atoss 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 judges 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 Accentures 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 technicallegal level, is largely unremarkable. Three points are worthy of note to those interested in the law andIT 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 partys 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.ConclusionsA software development project can work on a waterfall or an agile basis, but the basics have to be inplace in either scenario in order for the project to succeed. Make sure you have the basics covered.For example: For both parties, burying ones 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 customers 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 suppliers 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 suppliers perspective if you are required contractually to understand how a customers 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

×