'Why the Waterfall Contract is Flawed'

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.
Introduction
Agile 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. There
half their organisation’s software projects used an Agile are a number of different types of Agile development
methodology. Large companies such as IBM, BSkyB, methods, and often, several are used in conjunction. The
BT and British Airways are now converts. Even the US most popular versions are probably Scrum, Xtreme
Defense Department has been mandated to deliver IT Programming (XP), DSDM and Crystal. Central to each
systems 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 software
software in short-term projects with low capital early and often.
expenditure and visibility throughout the process, enabling Agile divides a software development project into small
them to assess their return on investment at regular cycles—often referred to as “iterations”, which are each
intervals. 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 software
catch up with the change in approach for the development development cycle including planning, requirements
of 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 is
waterfall 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 upon
this 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 processes
that 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 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 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. 180 Computer and Telecommunications Law Review
The waterfall model enshrines a sequential cent are rarely used. The simplest way to cut costs and
development process, in which development is seen as speed up development is to stop cutting code that serves
flowing steadily downwards—like a waterfall—through no purpose!
the phases of conception, initiation, analysis, design, The practice of the customer producing a written list
construction and testing. The output of each phase of its requirements is a fairly blunt and crude tool for
provides the input for the next stage. All of the determining what the customer actually needs. Although
requirements of the customer need to be specified before the customer can generally articulate its existing problem
any 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 use
customer tests whether the software meets its of language, often alternating between the generic and
requirements, and if it does so by a certain date the the specific. Generic language gives the supplier freedom
software is accepted. All of the contractual rights and to innovate but is often too vague to be contractually
remedies of the customer, together with its payment enforceable. Specific language is contractually
obligations, revolve around the software meeting the enforceable but often does not fit well within the overall
requirements by a certain date. solution that the supplier has to offer.
Further exacerbating the problem, the developers often
Flaws in the waterfall contract can’t understand the customer’s requirements. But
because the requirements assume a contractual
The waterfall contract is fundamentally flawed in five significance and the fees may have agreed on the basis
key 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 the
These flaws are so fundamental to the operation and effect requirements as set out in the contract. Instead of
of the waterfall contract that it is not possible to “tweak” facilitating change, contractual change control
it to accommodate an Agile approach to software mechanisms actually serve to restrict change. The whole
development. It is only by examining each of these flaws process of documenting changes consumes valuable
in turn that an understanding of the true nature of a resources, can be expensive to implement, does not add
contract 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 software
The practice of specifying the requirements of the simply in terms of whether it meets the customer’s
customer in a schedule to the contract—sometimes requirements as set out in the contract is not terribly
referred to as the big requirements up front (the BRUF) sophisticated. There is much more to good design than
doesn’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 the
starts and at a time when the customer’s knowledge and idiosyncrasies of the customer’s activities. It should work
understanding of the ultimate solution is at its least well as a smooth cohesive whole; and it should maintain its
formed. Over the course of the project the customer’s usefulness over time and evolve gracefully as it adapts
knowledge and understanding will inevitably increase. It to the future. But there is no recognition of these other
therefore seems completely counter-intuitive that the aspects to good design in the waterfall contract.
customer should be asked to make a decision on what it
wants 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 of
they want at the beginning of a project they tend to ask several layers through which the requirements should
for everything they think they might need, especially if flow before they reach the programmers. The customer
they think they will only get one shot at it. This inevitably provides the requirements for inclusion in a schedule to
leads to an unintended increase in the scope of the project. the contract. These are then handed to the analysts who
In 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. Why the Traditional Contract for Software Development is Flawed 181
will make the day-to-day decisions on exactly how to quality: scope (features and functionality), resources (cost
write the code. But the programmers are two or three and budget) and schedule (time).4 Ambler argues that it
documents away from an understanding of what the is unrealistic to fix or lock in all three of these. If there
customer wants. At each document hand-off, a are any uncertainty or unforeseen events in the software
considerable amount of information has been lost or development process, there is no room for give. In the
misinterpreted, not to mention key details and future end, if the project team delivers at all, the quality of the
perspectives 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 that
designers to take a depth-first approach to design. In other at least one of the three variables of the iron triangle
words, the designers are forced to make low-level should not be fixed up front, so that there is flexibility to
dependent decisions before experiencing the consequences accommodate any unknowns in the project.
of the high-level decisions. The most costly mistakes are
made by forgetting to consider something important at Contractual acceptance tests
the beginning. The easiest way to make such a big mistake
is 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 a
that the production of working software does not take certain key date, the software is accepted, and if it fails
place until the end of the development chain. This means the customer is entitled to contractual remedies. In other
that it can be many months, or even years, before the words, testing in the waterfall contract is used as a
customer has sight of working software. The design paper contractual tool, resulting in contractual rights for the
does 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 what
customer sees the working software that it can sensibly the true nature of testing should be. It should not be a
comment on the design. By this stage it is often too combative exercise resulting in the parties taking
expensive 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 stages
over-run in a software development project, it is typically throughout the process to provide valuable checks and
the testing process, which is at the end of the sequential feedback. It is by means of testing that the developers
chain, 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 extent
way 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 lines
the software as a whole has passed the relevant tests. In of test code as there are of product code. The test code
project management terms non-working code represents continues with the product code, and is used in making
waste: it may never be put into production. And the longer ongoing updates to the product code once it has been
the 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 software
that meets the customer’s requirements by a certain key
development would suggest that it is a service. It is a
date. In other words, the parties have agreed to a fixed
problem-solving exercise that involves discovering
price, 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 been
Agile, there are three main variables in a software
referred to as the “try it, test it, fix it” approach. For
development project, which together combine to affect
complex problems it is wholly inappropriate to use a
4
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. 182 Computer and Telecommunications Law Review
“right first time approach”. So there need to be multiple Conclusion
iterations of “try it, test it, fix it”. Actual software
The waterfall contract is fundamentally flawed. It is
development as embraced by Agile is very definitely a
inappropriate for use with Agile ways of working as the
contract 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 requirements
to bring a certain rigour or standard to the process, but
they seek to implement. But more importantly, the
they are not willing to commit in advance to what the
waterfall contract imposes contractual constraints that
eventual outcome of the software will be. A key feature
are damaging to the success of any software development
and benefit of the Agile method is that the outcome will
project. This is because the waterfall contract reinforces
evolve over the course of the project. Agile suppliers
some of the worst practices of the waterfall method. It is
expect, and even welcome, changing requirements during
imperative that the legal profession revisits the contractual
the 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