Agile is the latest buzzword that's got the software industry humming. But what does it really mean to be agile? In this column, Linda Hayes explores the original theory of the process and how this methodology manifests into action.
The agility craze is starting to scare me. Agility seems to have become shorthand for fast, as in "we are becoming more agile by having monthly releases." But you are not agile because you are faster, you are faster because you are agile. In fact, if you do nothing but shorten your release cycles and leave everything else the same, you will get less done than before.
Understanding how agile development makes you faster—and not the other way around—is the key to making agile work.
The core difference between agile development and traditional methods is being change-friendly. This does not mean smiling while you make changes; it means expecting change and enabling it by minimizing its impact. Said another way, you gain speed by reducing friction. This translates into less formality and related overhead.
In the waterfall model you start with business requirements, which in turn are used to develop functional requirements. As the process continues, functional requirements are used to describe use cases, which are validated by test cases and documented for end-users. Software is organized around a high-level design, and then the details of the software are explained in a low-level design that is converted into code. This step-wise progression actually avoids change: We imagine that by taking a methodical, thorough approach, we can prevent the necessity of making changes down the line.
The agile method turns this logic on its head, asserting that change is the norm. Software reflects the needs of its users who operate in a dynamic organization within a competitive marketplace. Therefore you can never truly predict what will be needed—you can only adapt. To avoid making changes to multiple expressions of the same functionality, requirements are boiled down to index cards; functional requirements and use cases collapse into test cases; and the code expresses the design.
Thus by reducing the sheer volume of output, we reduce the effort needed to change it.
Another way of enabling change in the agile model is through smaller iterations. Not just shorter, but smaller. Instead of gathering all possible requirements and then distributing them over a series of iterations, you focus only on the iteration in front of you. As soon as the planning horizon expands, you become more resistant to change: Refining the last iteration can come only at the expense of the next one, which throws you off schedule.
The thinking behind this is that users really don't know what they want until they see it. Requirements written as prose can be interpreted many different ways, but code operates only in one way. History is rife with missed or misunderstood requirements that are uncovered only at the last minute, when the software is finally exposed to users.
So the more quickly users can interact with the software, the sooner you will know whether it meets their requirements and the less you will have to change if it doesn't.
Resistance to agile methods, whether openly expressed or quietly feared, arises because agile methodologies introduce uncertainty. You can't predict the next iteration, let alone the actual release, because each one may include a new functionality or consist of tweaking previous features. And if you can't predict iterations, how can you plan for releases?
Furthermore, less formality increases the risk downstream of unexpected impact from change. Without an understanding of how everything fits together, the thinking goes, future developers are more likely to make mistakes. And, without requirements and use cases, future testers will be more likely to miss functionality.
To many, agility feels a lot like throwing caution to the wind and plunging headlong toward chaos. After all, traditional processes arose out of necessity—through lessons learned.