Verlag Dr. Otto Schmidt 30.09.2016 CRi 6/2010 161 John P. Beardwood /Michael Shour Risk Management and Agile Software Development: Optimizing Contractual Design A recent report from Forester Research(Dr. Dobb’s I. Understanding (FR)AGILE Software Global Developer Technographics Survey Q3 2009) asked a cross-selection of 1298 IT professionals to iden- 1. Traditional Software Development tify which methodology most closely reflected the devel- Agile is perhaps best understood by contrasting it to opment process that such professional was currently Waterfall methods of development. The traditional using. At 35 %, the most popular response was Agile, in plan-driven software development model of the Water- comparison to a mere 13 % who responded that Water- fall process was initially conceived to manage the devel- fall was their current methodology of choice. Put opment of large software projects in the 1960s, such as another way, three times as many IT professionals used IBM’s System/360 operating system. Waterfall arranges Agile methodologies as did those who used Waterfall. software development into a sequential series of com- partmentalized phases, each with its own defined deli- Over the last ten years, Agile software development verables. A typical Waterfall process will be comprised methodologies – those which take an iterative and incre- of the following phases: requirements analysis; project mental approach, which aim to reduce unnecessary doc- planning and system design; coding; and integration and umentation and formality, and which seek to promote testing. 1 teamwork and experimentation – have increasingly been adopted by the software development community. The Waterfall process is characterized by planning, Agile’s advocates argue that by liberating programmers organization, and documentation. At the outset of a from the shackles of traditional rigid, formalized devel- Waterfall process, there will be a great deal of emphasis opment methodologies, Agile has no equal for speed of on gathering and defining the business requirements – development, for efficiency, and for fostering creativity. that is, the “raw data” as to the what the customer Agile’s critics counter that Agile is another name for wants. Through formal meetings and analysis, a highly “cowboy coding”, or undisciplined “hacking”, which detailed requirements document is developed. Once the produces less robust and buggier software. From a legal requirements are set out in the requirements document, perspective, however, the question is not whether Agile a system design document is developed, with a set of spe- is a superior development methodology. Rather, the cifications 2 – or design “roadmap” – as to how those question is whether a contract for software development requirements will be achieved through software design. using Agile needs to be differently structured, and From an operational point of view, the process of devel- include different content, than where the development is oping the specifications involves the customer, and thus using Waterfall. This paper argues that the answer is an can itself assist in clarifying the requirements of the cus- emphatic yes. tomer. From a contractual point of view, however, if there are ever disputes, or any ambiguity, as to what was The paper begins by examining the differences between, promised to the customer, this also can be clarified and the advantages and disadvantages of each of, the through an examination of these documents. Waterfall and Agile development methodologies and examines how Agile is not single, monolithic methodol- Once the design specifications have been developed, the ogy, and that it in fact suffers from some definitional project is divided into distinct modules with detailed problems (e.g. when does Iterative programming transi- deliverables. Each module can be assigned to a different tion into Agile?), by briefly reviewing some of the major programming team, with each team being responsible Agile methodologies (I.). The paper then summarizes the for programming, testing, and debugging their respec- developing consensus as to when Agile will, or will not, tive module. Since the deliverables for each module are be an appropriate methodology for a development pro- clearly set out in the planning documents, the program- ject (II.). mers need not be well-rounded, highly-skilled program- mers, but merely need to be sufficiently skilled to under- Having provided a briefing on Agile as a methodology, stand the requirements and carry out their respective the paper then highlights the risks of Agile, and potential tasks. Test plans and reports are produced to ensure that contractual strategies for responding to and mitigating each module meets the specifications. If any changes are such risks (III.). 1 Michael A. Cusumano and Stanley Smith , Beyond the Waterfall: Soft- ¸ John P.Beardwood and Michael Shour are of the law firm Fasken Mar- ware Development at Microsoft (Working Paper #3844-BPS-1995, MIT tineau DuMoulin LLP, Toronto. John is a partner, Co-Chair of the Sloan School of Management and International Business Machines). firm’s National Technology and Intellectual Property Practice Group, The Waterfall model was first described by Winston W.Royce , “Manag- and Co-Chair of the Outsourcing Practice Group. Michael is an asso- ing the Development of Large Software Systems,” Proceedings of IEEE, ciate in the Business Law Group. This is a general overview of the sub- August, 1970. ject matter and should not be relied on as legal advice. For specific legal 2 Thetermsarenotalwaysutilizedsoclearly,inthatarequirements docu- advice on the topic and related matters, please contact the authors. Fur- ment is sometimes called a “requirements specification” i.e. simply the ther information about the authors at p. 192. requirements written down on paper. Exemplar für John Beardwood Verlag Dr. Otto Schmidt 30.09.2016 162 Beardwood/Shour CRi 6/2010 Risk Management and Agile Software Development: Optimizing Contractual Design requested or required, a formalized and well-docu- ¸ More isolated from collegial/customer feedback: mented change management process is followed and Segmenting the project into modules, to be com- change management forms must be completed. After the pleted by different teams, discourages cohesion and coding stage, the modules are assembled, tested, and creativity amongst the development team, reduces debugged, often with significant time spent rewriting valuable customer/user input, and often results in code to ensure the modules integrate properly. 3 design flaws not being discovered until well into the testing phases. As a consequence, integration and The planning and documentation associated with the acceptance both carry a significant portion of the Waterfall process yields some obvious benefits: operational and legal risk involved in a Waterfall ¸ Limited, targeted customer involvement: The busi- development project. ness people who are consulted in developing the specifications are required to invest time at the early stages. Once the specifications have been developed, 2. What is Agile Software? however, their involvement is generally limited to the Although the traditional Waterfall method has worked final integration and testing phase, allowing them to well for many large projects, some argue that different carry on with their primary business functions. programming methods are suitable for different pro- jects, and that not all projects fit well into the compart- ¸ Clear budgeting: Clear specifications and timelines mentalized and formalized traditional Waterfall pro- allow developers to make accurate bids for the work, cess. 5 While there are a number of software development while allowing the procurer to effectively budget for methodologies that are viewed as Agile, what those the project. methodologies have in common is that all generally seek ¸ Single development roadmap: For contracting pur- to move away from the traditional approach – where poses, the detailed specifications lead to a require- there is a great deal of up-front planning, a master docu- ments document that is useful from the perspective ment, and one or few iterations – towards an iterative of both the developer and the customer; once work and incremental approach, with less documentation begins, large teams – even those spread out over dif- and formality, and more teamwork and experimenta- ferent geographic locations – can follow the detailed tion. 6 requirements and development milestones over lon- In 2001, a group of software developers and consul- ger time horizons. tants, all champions of different Agile methods, came ¸ Divisible modules: Once the project is divided into together to publish the Agile Software Development specific modules with clear deliverables, outsourcing Manifesto. 7 While the principles of the Agile Manifesto or subcontracting one section of the project becomes are attached here as Appendix A, in summary the central possible. values of all Agile process are: individuals and interac- tions over processes and tools; working software over ¸ Benchmark for change management: If any changes comprehensive documentation; customer collaboration are requested or required, an examination of the over contract negotiation; and responding to change requirements and design documents allow the pro- over following a plan. 8 As some of these central values, ject manager to quickly determine the impact of the such as the deliberate lack of comprehensive documen- change on the timeline, cost,