Why the Traditional Contract for Software Development is Flawed

Transcription

1 Why the Traditional Contract for Software Development is Flawed Susan Atkinson Introduction Agile has entered the mainstream. In a recent survey, more than 50% of the respondents said that at least half their organisation's software projects used an Agile methodology. Large companies such as IBM, BSkyB, BT and British Airways are now converts. Even the US Defense Department has been mandated to deliver IT systems incorporating Agile principles. 1 Organisations are increasingly looking to develop software in short-term projects with low capital expenditure and visibility throughout the process, enabling them to assess their return on investment at regular intervals. But, by and large, the legal profession has failed to catch up with the change in approach for the development of software. The vast majority of contracts for the development of software are still based on the traditional waterfall technique. As far back as 2003 Mary and Tom Poppendieck 2 had this to say of the waterfall contract: "The contract-inspired model of project management generally favors a sequential development process with specifications fixed at the start of the project, customer sign-off on the specifications, and a change authorisation process intended to minimize changes. There is a perception that these processes give greater control and predictability, although sequential development processes with low feedback have a dismal record in this regard.... The conventional wisdom in project management values managing scope, cost and schedule to the original plan.... This mental model is so entrenched in project management thinking that its underlying assumptions are rarely questioned. This might explain why the waterfall model of software development is so difficult to abandon." An analysis of the assumptions underlying the waterfall contract is long overdue. This article reexamines the key features of the waterfall contract, and explains why it is fundamentally flawed. Agile Methods The essence of Agile software development methodology is best encapsulated by the Agile Manifesto: 3 individuals and interactions over processes and tools; National Defense Authorization Act, under which President Obama gave Defense Department officials a deadline of July 2010 to create new acquisition processes that can deliver IT systems in no more than 18 months by incorporating certain Agile principles. 2 Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck. The Poppendiecks have been very influential in the lean 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 Please refer to gallenalliance Solicitors,

2 working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. That is, while there is value in the items on the right, the Agile Alliance values the items on the left more. There are a number of different types of Agile development methods, and often, several are used in conjunction. The most popular versions are probably Scrum, Xtreme Programming (XP), DSDM and Crystal. Central to each of these methods is a common objective of minimizing risk by delivering value in the form of working software early and often. Agile divides a software development project into small cycles - often referred to as iterations', which are each typically 1-4 weeks in duration. During each iteration a team works through a full software development cycle including planning, requirements analysis, design, coding, testing and review. Fully tested, working software that is capable of being deployed is delivered at the end of each iteration. Subsequent iterations result in additional software that builds upon or complements the software that has already been delivered. The benefits of this approach to software development are numerous. Frequent and regular development cycles promote and facilitate a speed of implementation, regular feedback leads to a continuous improvement in terms of both learning and understanding, and the customer has the opportunity to prioritise those features which are of most value at regular intervals. The Waterfall Model However, as highlighted by the Poppendiecks, the typical contract for the development of software is based on the traditional waterfall method. The waterfall model enshrines a sequential development process, in which development is seen as flowing steadily downwards - like a waterfall - through the phases of conception, initiation, analysis, design, construction and testing. The output of each phase provides the input for the next stage. All of the requirements of the customer need to be specified before any design or development can begin. 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, together with its payment obligations, revolve around the software meeting the requirements by a certain date. Flaws in the Waterfall Contract The waterfall contract is fundamentally flawed in five key respects: (i) (ii) (iii) (iv) (v) The requirements are fixed at the start of the project. It mandates that analysis, design, development and testing occur sequentially. Scope, resources and schedule are fixed at the start of the project. Testing is used as a contractual tool. The contract is based upon a contract for the supply of goods. These flaws are so fundamental to the operation and effect of the waterfall contract that it is not possible to "tweak" it to accommodate an Agile approach to software development. It is only by examining each of these flaws in turn that an understanding of the true nature of a contract based on an Agile approach can be ascertained. The Big Requirements Up Front The practice of specifying the requirements of the customer in a Schedule to the contract - sometimes referred to as the Big Requirements Up Front (the "BRUF") doesn't work on several counts. gallenalliance Solicitors,

3 By definition, the contract is written before the project starts and at a time when the customer's knowledge and understanding of the ultimate solution is at its least well formed. Over the course of the project the customer's knowledge and understanding will inevitably increase. It therefore seems completely counter-intuitive that the customer should be asked to make a decision on what it wants at a time when it is least well equipped to do so. Since customers generally don't know exactly what they want at the beginning of a project they tend to ask for everything they think they might need, especially if they think they will only get one shot at it. This inevitably leads to an unintended increase in the scope of the project. In 2002 the Standish Group found that 45% of the features in a typical system are never used and 19% are rarely used. The simplest way to cut costs and speed up development is to stop cutting code that serves no purpose! The practice of the customer producing a written list of its requirements is a fairly blunt and crude tool for determining what the customer actually needs. Although the customer can generally articulate its existing problem very well, it is less good at describing a possible solution. To make matters worse, the customer struggles in its use of language, often alternating between the generic and the specific. Generic language gives the supplier freedom to innovate but is often too vague to be contractually enforceable. Specific language is contractually enforceable but often does not fit well within the overall solution that the supplier has to offer. Further exacerbating the problem, the developers often can't understand the customer's requirements. But because the requirements assume a contractual significance and the fees may have agreed on the basis of those requirements, instead of the parties working together to ascertain the meaning of the requirements, the parties are driven to adopt a defensive approach in resolving any ambiguity in the requirements. It is inevitable that the customer's requirements as set out in the contract will evolve over the life of the project. Business requirements change, the regulatory environment changes, the IT infrastructure changes. But the waterfall method does not accommodate change within the development process. As a result, the parties have to fall back on change control mechanisms for changing the requirements as set out in the contract. Instead of facilitating change, contractual change control mechanisms actually serve to restrict change. The whole process of documenting changes consumes valuable resources, can be expensive to implement, does not add value to the development process and generally serves to polarise the interests of the parties. Finally, these days, an evaluation of the software simply in terms of whether it meets the customer's requirements as set out in the contract is not terribly sophisticated. There is much more to good design than whether it incorporates a specified set of features. It should be intuitive to use. It should deal with the idiosyncrasies of the customer's activities. It should work as a smooth cohesive whole; and it should maintain its usefulness over time and evolve gracefully as it adapts to the future. But there is no recognition of these other aspects to good design in the waterfall contract. Sequential Development A traditional waterfall contract mandates a chain of several layers through which the requirements should flow before they reach the programmers. The customer provides the requirements for inclusion in a schedule to the contract. These are then handed to the analysts who perform an analysis and hand the results to the designers. The designers design the software and then hand the results to the programmers. It is the programmers who will make the day-to-day decisions on exactly how to write the code. But the programmers are two or three documents away from an understanding of what the customer wants. At each document hand-off, a considerable amount of information has been lost or misinterpreted, not to mention key details and future perspectives that were not obtained in the first place. A process of sequential development forces the designers to take a depth-first approach to design. In other words, the designers are forced to make low-level dependent decisions before experiencing the consequences of the high-level decisions. The most costly mistakes are made by forgetting to consider something important at the beginning. The easiest way to make such a big mistake is to drill down to detail too fast. gallenalliance Solicitors,

4 A further consequence of sequential development is that the production of working software does not take place until the end of the development chain. This means that it can be many months, or even years, before the customer has sight of working software. The design paper does not give any real indication of what the working software will look like, and often it is only when the customer sees the working software that it can sensibly comment on the design. By this stage it is often too expensive to accommodate many of the changes that the customer may request. Testing happens even later in the chain. If there is any over-run in a software development project, it is typically the testing process, which is at the end of the sequential chain, that is squeezed. This means that there is even less opportunity for checking that the software operates in the way intended and meets the needs of the customer. The customer cannot use any aspect of the code until the software as a whole has passed the relevant tests. In project management terms non-working code represents waste: it may never be put into production. And the longer the wait until the software is put into production, the greater the waste, and the lower the return on investment. The 'Iron Triangle' Typically, under a waterfall contract the customer pays the supplier a fixed fee for the development of software that meets the customer's requirements by a certain key date. In other words, the parties have agreed to a fixed price, a fixed set of requirements and a fixed timetable. According to Scott Ambler, a leading advocate of Agile, there are three main variables in a software development project, which together combine to affect quality: Scope (Features and Functionality), Resources (cost and budget) and Schedule (time). 4 Ambler argues that it is unrealistic to fix or lock in all three of these. If there is any uncertainty or unforeseen events in the software development process, there is no room for give. In the end, if the project team delivers at all, the quality of the delivered product suffers, and the project is almost always late and over budget anyway. Ambler's solution is that at least one of the three variables of the iron triangle should not be fixed up front, so that there is flexibility to accommodate any unknowns in the project. Contractual Acceptance Tests A key feature of the waterfall contract is that if the software successfully passes the acceptance tests by a certain key date, the software is accepted, and if it fails the customer is entitled to contractual remedies. In other words, testing in the waterfall contract is used as a contractual tool, resulting in contractual rights for the customer if the software does not meet its requirements. This has a very damaging and destructive impact on what the true nature of testing should be. It should not be a combative exercise resulting in the parties taking positions. Instead, testing should be an integral part of the process for improving the design. It should happen at all stages throughout the process to provide valuable checks and feedback. It is by means of testing that the developers can make changes throughout the development process. One of the measures of well written code is the extent to which it has been tested. Interestingly, for a well written software system, there may be as many lines of test code as there are of product code. The test code continues with the product code, and is used in making ongoing updates to the product code once it has been deployed. 4 Scott Ambler is the Chief Methodologist for Agile and Lean within IBM Rationale, and is a leading proponent of the Agile movement. gallenalliance Solicitors,

5 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 arguably this is slotted into a contractual structure for the supply of goods. However, an analysis of what is involved in software development would suggest that it is a service. It is a problem-solving exercise, that involves discovering solutions through short, repeated cycles of investigation, experimentation and checking the results. This has been referred to as the "try it, test it, fix it" approach. For complex problems it is wholly inappropriate to use a "right first time approach". So there need to be multiple iterations of "try it, test it, fix it". Actual software development as embraced by Agile is very definitely a contract for the supply of services. Agile suppliers are typically offering customers a technique or a capability, not an outcome. They commit to bring a certain rigour or standard to the process, but they are not willing to commit in advance to what the eventual outcome of the software will be. A key feature and benefit of the Agile method is that the outcome will evolve over the course of the project. Agile suppliers expect, and even welcome, changing requirements during the project, even at a late stage. Conclusion The waterfall contract is fundamentally flawed. It is inappropriate for use with Agile ways of working as the formalised specifications, processes and deadlines mandated for a project often conflict with the informal, complex and constantly evolving business requirements they seek to implement. But more importantly, the waterfall contract imposes contractual constraints that are damaging to the success of any software development project. This is because the waterfall contract reinforces some of the worst practices of the waterfall method. It is imperative that the legal profession revisits the contractual basis for the procurement of software development. Note: If you are interested in receiving the next article (currently under pen) which analyses the key features of an Agile contract, please contact Susan Atkinson at [email protected]. United Kingdom: gallenalliance, 12th Floor, The Broadgate Tower, No.20 Primrose Street, London EC2A 2EW, England Ireland: gallenalliance, Business Centre, No.1 Lower Mayor Street, International Financial Services Centre, Dublin 1, Ireland OM 01DOC gallenalliance Solicitors,