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.

Reducing Friction
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.

Increasing Velocity
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.

Expanding Uncertainty
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.Expanding Involvement
While it is true that the waterfall and similar methods evolved for a reason, it is also true that many of those reasons are no longer valid. The earliest uses for computers centered on improving productivity by making a manual process faster, and code was carefully flow-charted and hand-constructed from scratch. Software development could—and did—take years to accomplish.

Today, however, software is centered on competition-enabling processes and products that cannot possibly be reproduced manually, often by rapid assembly of components and services. It's no longer about being productive, it's about being viable. The entire market landscape can change dramatically in a year, so speed is not just desirable, it is imperative. No one cares about tax software that is perfect if it is delivered on April 16.

So how do you compensate for less formality and a shorter planning horizon? Expand the involvement of all stakeholders.

Instead of using documents to exchange information sequentially among users, analysts, developers, testers, and technical writers—each accountable for her own piece within a schedule that dictates when each task must be completed—the agile approach demands instant, direct, face-to-face communication as a group. It takes less time to speak and listen than to write and read, and ambiguities are exposed more easily and interactively through discussion than through edits. This way, content drives the schedule instead of the other way around.

But perhaps the most profound implication of this approach is that it is no longer the business demanding delivery dates from IT, but rather the business deciding when it has what it needs. This shift of responsibility is crucial, because the longer IT is held hostage to delivering "on time," the greater the need to defend itself against change.

And that, it seems to me, is what management often misses when thinking about agility. Managers imagine agile changing the way IT operates, when in fact agile requires change throughout the entire organization. Unless and until the business accepts its new role and responsibility in this model, agile development will join the list of fads that promised more than it could deliver.