Why Agile Projects Don't Thrash

Tension. It's there on every software project. Tension comes from the stress of ensuring the software is fit for its purpose. And if our first assessment of what's needed is off, we have to change things around until we get them right. But we must also finish on time and on budget, so there's a need for stability

In contrast, the so-called "Agile" approaches don't just welcome change, they practically demand it. Even worse, they start building—and even shipping—features before the requirements have all been nailed down. Agile teams will deliver features in any order the customer wants, and they'll let the customer change her mind about that order at any time.

Starting before you know what has to be done, much less how to do it? Changing your mind every couple of weeks? This sounds like a recipe for thrashing. Yet Agile projects generally don’t thrash. Why not?

Overall Status and Progress
At the project and release level, Agile approaches include ways of knowing how close you are to finished. One very popular approach is the "burn-up chart." A simple burn-up chart is shown in Figure 1. The finish line at the top represents all the needed features. After each iteration, the chart is extended to show the number of features that are actually complete, running, and tested.

With a chart like this, you can see directly when you’re likely to be finished: Extend the curve of feature growth and estimate when it will cross the finish line. This chart will readily detect thrashing. If the customer adds new features, the finish line goes up, as in Figure 2. This simple tracking is made possible by Agile methods' focus on features. (See the "Control Elements in Agile Projects" sidebar.) Add in direct business involvement and you have the ability and incentive to see that the goal line is receding, and now is the time to do something about it.

Known Cost, Short Cycles, Fixed Capacity
Agile iterations are short, uninterruptible, time-boxed periods where the team works on batches of features. In order to know how much they can accomplish, Agile projects generally know the cost of features, either individually or as batches.

Agile iterations are a few weeks long. Therefore, every couple of weeks, everyone gets a chance to look at the team's progress to see whether the current progress suggests that the team will, or will not, have all the features in time.

Agile teams know how much they can do in each iteration. They don't get pushed into taking on a lot of features that they can't deliver. Instead, they learn to estimate accurately what they can do and to deliver on those estimates.

If the customer changes her mind and wants to add a new feature, or even have an old one redone, that is her privilege. In fact, it is her duty: She is responsible for taking advantage of all that has been learned so far to decide what to do next. But because in each iteration she has a finite budget of features that the team can do, she is faced with choices all the time, so she learns to make good ones.

The uninterruptible character of iterations creates a desirable tension around change. The Product Owner knows she can't change her mind for a while, so she feels a bit of pressure to make good decisions. Does she have some brilliant new idea? Then, because she has a fixed budget, she must defer something of the same size.

Because changes have a tangible cost, change hurts a bit, just enough so that