I read with dismay “The Agile Methods Fray”, where two of the luminaries of software processes discuss traditional (defined) and agile approaches. The discussion was irrelevant to those attempting to understand the distinction. A sentence characterized the apparent purpose of the article, “ …found a sensible middle ground and identifying some baby to be saved and some bathwater to be replaced.”
There is no middle ground between traditional and agile processes. The practices of traditional software development processes are inadequate to control projects with complex technology and sophisticated requirements. Agile processes are based on empirical process control, a technique widely adapted by competitive manufacturing and development environments over the last twenty years. I quote from the bible of process control (Process Dynamics, Modeling, and Control, Ogunnaike and Ray, Oxford University Press, 1992), “It is typical to adopt the defined (theoretical) modeling approach when the underlying mechanisms by which a process operates are reasonably well understood. When the process is too complicated for the defined approach, the empirical approach is the appropriate choice.”
Empirical process control relies on frequent inspection and continuous adaptation to minimize risk and produce quality product. Agile processes implement empirical process control through iterations, frequent increments of working, tested functionality, emergence of requirements and architecture, self-organization of multiple small teams, and collaboration. These are not spot practices shared by defined and agile processes since the underlying theory is different … using a defined approach for a complex problem is like using algebra to solve complex, non-linear problems.
We indeed are in the middle of a revolution, as we shed traditionally weak and inadequate practices and adopt agile processes. The issue isn’t merging the two, but successfully managing the change. Those who wish to tinker with either to reach a middle ground tread a dangerous path toward misleading those who rely on them for informed advice.
One of the developer of the Scrum agile process
One of the founders of the AgileAlliance email@example.com