Risk Management and Agile Software Development: Optimizing Contractual Design

Abstract

A recent report from Forester Research(Dr. Dobb's Global Developer Technographics Survey Q3 2009) asked a cross-selection of 1298 IT professionals to identify which methodology most closely reflected the development process that such professional was currently using. At 35 %, the most popular response was Agile, in comparison to a mere 13 % who responded that Waterfall was their current methodology of choice. Put another way, three times as many IT professionals used Agile methodologies as did those who used Waterfall. Over the last ten years, Agile software development methodologies - those which take an iterative and incremental approach, which aim to reduce unnecessary documentation and formality, and which seek to promote teamwork and experimentation-have increasingly been adopted by the software development community. Agile's advocates argue that by liberating programmers from the shackles of traditional rigid, formalized development methodologies, Agile has no equal for speed of development, for efficiency and for fostering creativity. Agile's critics counter that Agile is another name for cowboy coding, or undisciplined hacking, which produces less robust and buggier software. From a legal perspective, however, the question is not whether Agile is a superior development methodology. Rather, the question is whether a contract for software development using Agile needs to be differently structured, and include different content, than where the development is using Waterfall. This paper argues that the answer is an emphatic yes. The paper begins by examining the differences between, and the advantages and disadvantages of each of, the Waterfall and Agile development methodologies and examines how Agile is not single, monolithic methodology and that it in fact suffers from some definitional problems (e.g. when does Iterative programming transition into Agile?), by briefly reviewing some of the major Agile methodologies (I.). The paper then summarizes the developing consensus as to when Agile will, or will not, be an appropriate methodology for a development project (II.). Having provided a briefing on Agile as a methodology the paper then highlights the risks of Agile, and potential contractual strategies for responding to and mitigating such risks (III.).