Section 2.1. Agility Is Not Binary


2.1. Agility Is Not Binary

Currently, processes are divided into two distinct categories: agile and plan-driven. Each has a community, a variety of practices, and a list of successful applications of those practices. With a few notable exceptions, there is very little overlap between these categories. This gives the appearance that agility is a binary attribute. However, agility is not an all-or-nothing affair that we can achieve through a single change in the development process.

Instead of asking, "Are we agile?" and trying to initiate a single, dramatic process change that will "achieve" agility, a more appropriate perspective focuses on "To what degree are we agile?" Within its community, agility has been defined as "the ability to both create and respond to change."[5] We can answer this question by measuring the length of time between a requirement change and when we deliver the updated functionality to a customer. This length of time is known in Lean Software Development as cycle time.

Figure 2.1. Apparent distinction between agile and plan-driven methods


Agile methodologies have been designed to have very short cycle times when compared with plan-driven methodologies. In general, agile methods advocate releasing new functionality in fixed-length iterations, and the iteration length defines their cycle time. This is the most significant difference between agile and plan-driven methods: agile methods have a fixed cycle time that is relatively short, which lets the team adjust to changing customer needs rapidly.

Plan-driven (and ad hoc) methodologies define the length of time between releases by the functionality they want to be included in the release. As a result, releases are not of a fixed length, so they do not have a consistent cycle time. However, as a starting point, every process has a (possibly variable) cycle time and therefore some (possibly low) degree of agility.

With this perspective, agility is not a binary attribute and does not mandate a dramatic change in your process today. The current process has some degree of agility (though it may be slow and unstable) and defines a starting point on the path to improved agility. The challenge is to maximize the strengths of the current process and to make changes to that process in a disciplined manner with specific goals in mind.




Refactoring to Agility
Refactoring to Agility
ISBN: B000P28WK8
EAN: N/A
Year: 2006
Pages: 58

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net