CTLR 2010 Issue 7 Waterfall Contract


Published on

'Why the Waterfall Contract is Flawed'

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

CTLR 2010 Issue 7 Waterfall Contract

  1. 1. Why the Traditional Contract for Software Development is Flawed 179 assumptions are rarely questioned. This might Why the Traditional explain why the waterfall model of software development is so difficult to abandon.” Contract for Software An analysis of the assumptions underlying the waterfall contract is long overdue. This article re-examines the key Development is features of the waterfall contract, and explains why it is Flawed fundamentally flawed. Agile methods Susan Atkinson * Director, Corporate & Commercial Groups, The essence of Agile software development methodology is best encapsulated by the Agile Manifesto3: gallenalliance individuals and interactions over processes and tools; Computer contracts; Project management; Software working software over comprehensive documentation;development customer collaboration over contract negotiation; responding to change over following a plan.IntroductionAgile has entered the mainstream. In a recent survey, That is, while there is value in the items on the right,more than 50 per cent of the respondents said that at least the Agile Alliance values the items on the left more. Therehalf their organisation’s software projects used an Agile are a number of different types of Agile developmentmethodology. Large companies such as IBM, BSkyB, methods, and often, several are used in conjunction. TheBT and British Airways are now converts. Even the US most popular versions are probably Scrum, XtremeDefense Department has been mandated to deliver IT Programming (XP), DSDM and Crystal. Central to eachsystems incorporating Agile principles.1 of these methods is a common objective of minimising Organisations are increasingly looking to develop risk by delivering value in the form of working softwaresoftware in short-term projects with low capital early and often.expenditure and visibility throughout the process, enabling Agile divides a software development project into smallthem to assess their return on investment at regular cycles—often referred to as “iterations”, which are eachintervals. typically one to four weeks in duration. During each But, by and large, the legal profession has failed to iteration a team works through a full softwarecatch up with the change in approach for the development development cycle including planning, requirementsof software. The vast majority of contracts for the analysis, design, coding, testing and review. Fully tested,development of software are still based on the traditional working software that is capable of being deployed iswaterfall technique. delivered at the end of each iteration. Subsequent As far back as 2003 Mary and Tom Poppendieck2 had iterations result in additional software that builds uponthis to say of the waterfall contract: or complements the software that has already been delivered. “The contract-inspired model of project management The benefits of this approach to software development generally favors a sequential development process are numerous. Frequent and regular development cycles with specifications fixed at the start of the project, promote and facilitate a speed of implementation, regular customer sign-off on the specifications, and a change feedback leads to a continuous improvement in terms of authorisation process intended to minimize changes. both learning and understanding, and the customer has There is a perception that these processes give the opportunity to prioritise those features which are of greater control and predictability, although most value at regular intervals. sequential development processes with low feedback have a dismal record in this regard … The waterfall model The conventional wisdom in project management values managing scope, cost and schedule to the However, as highlighted by the Poppendiecks, the typical original plan … This mental model is so entrenched contract for the development of software is based on the in project management thinking that its underlying traditional waterfall method.* satkinson@gallenalliance.com.1 2010 National Defense Authorization Act, under which President Obama gave Defense Department officials a deadline of July 2010 to create new acquisition processesthat can deliver IT systems in no more than 18 months by incorporating certain Agile principles.2 Mary and Tom Poppendieck, Lean Software Development: An Agile Toolkit (Addison-Wesley Professional, 2003). The Poppendiecks have been very influential in thelean software movement, which has arguably been the inspiration for, and formed the basis of many of the principles of the Agile approach.3 The Agile Manifesto was developed by the Agile Alliance in 2001. Please refer to http://agilemanifesto.org/ [Accessed August 11, 2010]. [2010] C.T.L.R., Issue 7 © 2010 Thomson Reuters (Legal) Limited and Contributors
  2. 2. 180 Computer and Telecommunications Law Review The waterfall model enshrines a sequential cent are rarely used. The simplest way to cut costs anddevelopment process, in which development is seen as speed up development is to stop cutting code that servesflowing steadily downwards—like a waterfall—through no purpose!the phases of conception, initiation, analysis, design, The practice of the customer producing a written listconstruction and testing. The output of each phase of its requirements is a fairly blunt and crude tool forprovides the input for the next stage. All of the determining what the customer actually needs. Althoughrequirements of the customer need to be specified before the customer can generally articulate its existing problemany design or development can begin. very well, it is less good at describing a possible solution. The essence of the waterfall contract is that the To make matters worse, the customer struggles in its usecustomer tests whether the software meets its of language, often alternating between the generic andrequirements, and if it does so by a certain date the the specific. Generic language gives the supplier freedomsoftware is accepted. All of the contractual rights and to innovate but is often too vague to be contractuallyremedies of the customer, together with its payment enforceable. Specific language is contractuallyobligations, revolve around the software meeting the enforceable but often does not fit well within the overallrequirements by a certain date. solution that the supplier has to offer. Further exacerbating the problem, the developers oftenFlaws in the waterfall contract can’t understand the customer’s requirements. But because the requirements assume a contractualThe waterfall contract is fundamentally flawed in five significance and the fees may have agreed on the basiskey respects: of those requirements, instead of the parties working 1. The requirements are fixed at the start of together to ascertain the meaning of the requirements, the the project. parties are driven to adopt a defensive approach in 2. It mandates that analysis, design, resolving any ambiguity in the requirements. development and testing occur sequentially. It is inevitable that the customer’s requirements as set 3. Scope, resources and schedule are fixed at out in the contract will evolve over the life of the project. the start of the project. Business requirements change, the regulatory environment 4. Testing is used as a contractual tool. changes, the IT infrastructure changes. But the waterfall 5. The contract is based upon a contract for method does not accommodate change within the the supply of goods. development process. As a result, the parties have to fall back on change control mechanisms for changing theThese flaws are so fundamental to the operation and effect requirements as set out in the contract. Instead ofof the waterfall contract that it is not possible to “tweak” facilitating change, contractual change controlit to accommodate an Agile approach to software mechanisms actually serve to restrict change. The wholedevelopment. It is only by examining each of these flaws process of documenting changes consumes valuablein turn that an understanding of the true nature of a resources, can be expensive to implement, does not addcontract based on an Agile approach can be ascertained. value to the development process and generally serves to polarise the interests of the parties.The big requirements up front Finally, these days, an evaluation of the softwareThe practice of specifying the requirements of the simply in terms of whether it meets the customer’scustomer in a schedule to the contract—sometimes requirements as set out in the contract is not terriblyreferred to as the big requirements up front (the BRUF) sophisticated. There is much more to good design thandoesn’t work on several counts. whether it incorporates a specified set of features. It By definition, the contract is written before the project should be intuitive to use. It should deal with thestarts and at a time when the customer’s knowledge and idiosyncrasies of the customer’s activities. It should workunderstanding of the ultimate solution is at its least well as a smooth cohesive whole; and it should maintain itsformed. Over the course of the project the customer’s usefulness over time and evolve gracefully as it adaptsknowledge and understanding will inevitably increase. It to the future. But there is no recognition of these othertherefore seems completely counter-intuitive that the aspects to good design in the waterfall contract.customer should be asked to make a decision on what itwants at a time when it is least well equipped to do so. Sequential development Since customers generally don’t know exactly what A traditional waterfall contract mandates a chain ofthey want at the beginning of a project they tend to ask several layers through which the requirements shouldfor everything they think they might need, especially if flow before they reach the programmers. The customerthey think they will only get one shot at it. This inevitably provides the requirements for inclusion in a schedule toleads to an unintended increase in the scope of the project. the contract. These are then handed to the analysts whoIn 2002 the Standish Group found that 45 per cent of the perform an analysis and hand the results to the designers.features in a typical system are never used and 19 per The designers design the software and then hand the results to the programmers. It is the programmers who [2010] C.T.L.R., Issue 7 © 2010 Thomson Reuters (Legal) Limited and Contributors
  3. 3. Why the Traditional Contract for Software Development is Flawed 181will make the day-to-day decisions on exactly how to quality: scope (features and functionality), resources (costwrite the code. But the programmers are two or three and budget) and schedule (time).4 Ambler argues that itdocuments away from an understanding of what the is unrealistic to fix or lock in all three of these. If therecustomer wants. At each document hand-off, a are any uncertainty or unforeseen events in the softwareconsiderable amount of information has been lost or development process, there is no room for give. In themisinterpreted, not to mention key details and future end, if the project team delivers at all, the quality of theperspectives that were not obtained in the first place. delivered product suffers, and the project is almost always A process of sequential development forces the late and over budget anyway. Ambler’s solution is thatdesigners to take a depth-first approach to design. In other at least one of the three variables of the iron trianglewords, the designers are forced to make low-level should not be fixed up front, so that there is flexibility todependent decisions before experiencing the consequences accommodate any unknowns in the project.of the high-level decisions. The most costly mistakes aremade by forgetting to consider something important at Contractual acceptance teststhe beginning. The easiest way to make such a big mistakeis to drill down to detail too fast. A key feature of the waterfall contract is that if the A further consequence of sequential development is software successfully passes the acceptance tests by athat the production of working software does not take certain key date, the software is accepted, and if it failsplace until the end of the development chain. This means the customer is entitled to contractual remedies. In otherthat it can be many months, or even years, before the words, testing in the waterfall contract is used as acustomer has sight of working software. The design paper contractual tool, resulting in contractual rights for thedoes not give any real indication of what the working customer if the software does not meet its requirements.software will look like, and often it is only when the This has a very damaging and destructive impact on whatcustomer sees the working software that it can sensibly the true nature of testing should be. It should not be acomment on the design. By this stage it is often too combative exercise resulting in the parties takingexpensive to accommodate many of the changes that the positions.customer may request. Instead, testing should be an integral part of the process Testing happens even later in the chain. If there is any for improving the design. It should happen at all stagesover-run in a software development project, it is typically throughout the process to provide valuable checks andthe testing process, which is at the end of the sequential feedback. It is by means of testing that the developerschain, that is squeezed. This means that there is even less can make changes throughout the development process.opportunity for checking that the software operates in the One of the measures of well-written code is the extentway intended and meets the needs of the customer. to which it has been tested. Interestingly, for a The customer cannot use any aspect of the code until well-written software system, there may be as many linesthe software as a whole has passed the relevant tests. In of test code as there are of product code. The test codeproject management terms non-working code represents continues with the product code, and is used in makingwaste: it may never be put into production. And the longer ongoing updates to the product code once it has beenthe wait until the software is put into production, the deployed.greater the waste, and the lower the return on investment. A contract for the supply of goods An analysis of the waterfall contract would suggest that it is based on a contract for the supply of goods. The essence of the waterfall contract is that the customer tests whether the software meets its requirements, and if it does so by a certain date the software is accepted. All of the contractual rights and remedies of the customer revolve around the software meeting the requirements by a certain date. There is a certain element of services in the waterfall contract in the form of the software development, but Figure 1: The “iron triangle”. arguably this is slotted into a contractual structure for the Typically, under a waterfall contract the customer pays supply of goods.the supplier a fixed fee for the development of software However, an analysis of what is involved in softwarethat meets the customer’s requirements by a certain key development would suggest that it is a service. It is adate. In other words, the parties have agreed to a fixed problem-solving exercise that involves discoveringprice, a fixed set of requirements and a fixed timetable. solutions through short, repeated cycles of investigation, According to Scott Ambler, a leading advocate of experimentation and checking the results. This has beenAgile, there are three main variables in a software referred to as the “try it, test it, fix it” approach. Fordevelopment project, which together combine to affect complex problems it is wholly inappropriate to use a4 Scott Ambler is the chief methodologist for Agile and Lean within IBM Rationale, and is a leading proponent of the Agile movement. [2010] C.T.L.R., Issue 7 © 2010 Thomson Reuters (Legal) Limited and Contributors
  4. 4. 182 Computer and Telecommunications Law Review“right first time approach”. So there need to be multiple Conclusioniterations of “try it, test it, fix it”. Actual software The waterfall contract is fundamentally flawed. It isdevelopment as embraced by Agile is very definitely a inappropriate for use with Agile ways of working as thecontract for the supply of services. formalised specifications, processes and deadlines Agile suppliers are typically offering customers a mandated for a project often conflict with the informal,technique or a capability, not an outcome. They commit complex and constantly evolving business requirementsto bring a certain rigour or standard to the process, but they seek to implement. But more importantly, thethey are not willing to commit in advance to what the waterfall contract imposes contractual constraints thateventual outcome of the software will be. A key feature are damaging to the success of any software developmentand benefit of the Agile method is that the outcome will project. This is because the waterfall contract reinforcesevolve over the course of the project. Agile suppliers some of the worst practices of the waterfall method. It isexpect, and even welcome, changing requirements during imperative that the legal profession revisits the contractualthe project, even at a late stage. basis for the procurement of software development. [2010] C.T.L.R., Issue 7 © 2010 Thomson Reuters (Legal) Limited and Contributors