Research Commentary—Weighing the Benefits and Costs of Flexibility in Making Software: Toward a Contingency Theory of the Determinants of Development Process Design

Abstract

In recent years, flexibility has emerged as a divisive issue in discussions about the appropriate design of processes for making software. Partisans in both research and practice argue for and against plan-based (allegedly inflexible) and agile (allegedly too flexible) approaches. The stakes in this debate are high; questions raised about plan-based approaches undermine longstanding claims that those approaches, when realized, represent maturity of practice. In this commentary, we call for research programs that will move beyond partisan disagreement to a more nuanced discussion, one that takes into account both benefits and costs of flexibility. Key to such programs will be the development of a robust contingency framework for deciding when (in what conditions) plan-based and agile methods should be used. We develop a basic contingency framework in this paper, one that models the benefit/cost economics described in narratives about the transition from craft to industrial production of physical products. We use this framework to demonstrate the power of even a simple model to help us accomplish three objectives: (1) to refocus discussions about the appropriate design of software development processes, concentrating on when to use particular approaches and how they might be usefully combined; (2) to suggest and guide a trajectory of research that can support and enrich this discussion; and (3) to suggest a technology-based explanation for the emergence of agile development at this point in history. Although we are not the first to argue in favor of a contingency perspective, we show that there remain many opportunities for information systems (IS) research to have a major impact on practice in this area.

Overview and Guidance on Agile Development in Large Organizations

“…A number of academics and practitioners in the information systems community have discussed the increasing popularity of agile development methods and the implications of that growth [e.g., Austin and Devin, 2009;Conboy, 2009;. These articles seek to explore and explain the strengths and weaknesses of agile development listed above.…”

“…First, as mentioned, agile methods allow flexibility and adaptability [Austin and Devin, 2009]. Because the design phase is not formal and programmers work in short intervals on smaller milestones, significant requirements of the project can change as development proceeds without much loss of productivity.…”

An Investigation of the Decision-Making Process in Agile Teams

“…These include decisions for changing requirements, identifying problems that require resolution, and generating new ideas that need to be explored 10 . Agile teams are less structured than teams following the traditional SDLC.…”

An Empirical Examination of an Agile Contingent Project/Method Fit Model

“…Many prior studies have used contingency theory to study the notion of "fitting" software development practices to project context (Andres & Zmud, 2001;Austin & Devin, 2009;Barki, Rivard, & Talbot, 2001;Franz, 1985;Kyu Kim & Umanath, 1992;Mathiassen, Saarinen, Tuunanen, & Rossi, 2007 (2001) used the theory to study the influence of fit between project risk levels and project management practices on software development performance. Results suggest that the project management practices one uses need to vary based on the level of risks emanating from a project's complexity, rate of change, availability of information, and clarity of information.…”

“…Austin and Devin (2009) support a contingent perspective of agile SDM use and call on researchers to develop a "robust contingency framework for deciding when (in what conditions) planbased and agile methods should be used" (p. 462). As such, we address that call to action and empirically assess whether or not specific contextual factors influence software development professionals' perceptions regarding the fit (contextual appropriateness) of agile SDMs over plan-driven SDMs.…”