2015Communications of the Association for Information SystemsRequires access

Running on Hybrid: Control Changes when Introducing an Agile Methodology in a Traditional “Waterfall” System Development Environment

Lakshman Mahadevan, William J. Kettinger, Thomas O. Meservy

Open publisher page 43 citations

Abstract

Prior to implementing “Agile” software development methods, organizations rooted in traditional “Waterfall” software development employed heavy upfront project design and limited changes and feedback during and between project stages. Waterfall methods make heavy use of outcome controls primarily monitored by the information systems function (ISF). This paper explores the control mechanisms used by the ISF and business function (BF) during and after the introduction of a major Agile project at a large U.S. company steeped in the traditional Waterfall method. Outcome control, the predominant control mechanism used in the case company, gave way to a hybrid-like control that possessed mechanisms of emergent control while maintaining vestiges of some Waterfall-like outcome control. We observed that, prior to the introduction of Agile, the software-development process was firmly in the hands of the ISF. The introduction of Agile shifted some of the controller authority over the development process from the ISF to the BF. Lessons learned from the case study point to the complexity of designing control mechanisms during a transition from the Waterfall method to an Agile approach.

About this research paper

What this paper is about

Prior to implementing “Agile” software development methods, organizations rooted in traditional “Waterfall” software development employed heavy upfront project design and limited changes and feedback during and between project stages. Waterfall methods make heavy use of outcome controls primarily monitored by the information systems function (ISF). This paper explores the control mechanisms used by the ISF and business function (BF) during and after the introduction of a major Agile project at a large U.S. company steeped in the traditional Waterfall method. Outcome control, the predominant control mechanism used in the case company, gave way to a hybrid-like control that possessed mechanisms of emergent control while maintaining vestiges of some Waterfall-like outcome control. We observed that, prior to the introduction of Agile, the software-development process was firmly in the hands of the ISF. The introduction of Agile shifted some of the controller authority over the development process from the ISF to the BF. Lessons learned from the case study point to the complexity of designing control mechanisms during a transition from the Waterfall method to an Agile approach.

Why it matters

OpenAlex reports 43 citations for this work. Citation counts describe recorded attention and do not establish research quality.

Key contribution

A contribution statement is not available in the OpenAlex record.

Method / approach

Method details are not available in the OpenAlex metadata.

Main findings

Findings are not separately available in the OpenAlex metadata.

Limitations

Limitations are not available in the OpenAlex metadata.

Applications

Application details are not available in the OpenAlex metadata.

Available abstract

Prior to implementing “Agile” software development methods, organizations rooted in traditional “Waterfall” software development employed heavy upfront project design and limited changes and feedback during and between project stages. Waterfall methods make heavy use of outcome controls primarily monitored by the information systems function (ISF). This paper explores the control mechanisms used by the ISF and business function (BF) during and after the introduction of a major Agile project at a large U.S. company steeped in the traditional Waterfall method. Outcome control, the predominant control mechanism used in the case company, gave way to a hybrid-like control that possessed mechanisms of emergent control while maintaining vestiges of some Waterfall-like outcome control. We observed that, prior to the introduction of Agile, the software-development process was firmly in the hands of the ISF. The introduction of Agile shifted some of the controller authority over the development process from the ISF to the BF. Lessons learned from the case study point to the complexity of designing control mechanisms during a transition from the Waterfall method to an Agile approach.

Key concepts: Waterfall, Waterfall model, Agile software development, Lean software development, Engineering, Software development, Software development process, Computer science

Related papers

Back to paper searchBrowse research topicsOriginal source
Running on Hybrid: Control Changes when Introducing an Agile Methodology in a Traditional “Waterfall” System Development Environment — Research Paper | ScholarLens