Enough Is Enough

Agile software delivery is about doing enough up-front analysis, design, and planning—and then deferring decisions until the appropriate time. But what does "enough" mean? And why has the term "agile" become a cliché in development circles?

I recently was accused of being "post-agile," particularly in the context of behavior-driven development (see my article in the March 2006 issue of Better Software magazine for more on this topic). I am curious about this because I don’t see a difference between what I do and what I would consider agile software delivery.

The early practitioners of methodologies such as Extreme Programming (XP) and Scrum were reacting to an industry that equated writing software with the construction industry, where risks are managed by heavyweight engineering processes, Gantt charts, and exhaustive up-front analysis and architecture. They felt that software could be made malleable—so you would craft your application like clay, starting with a rough shape and gradually molding it into the form you wanted. No decision was final and every decision could be deferred.

Unfortunately, they went to an extreme—whether by intent or by accident—and seemed to be saying that you could get away with no up-front planning, analysis, or design as long as you were religiously following the twelve XP practices or having daily scrums. Just start "somewhere that looks interesting" and take it from there, trusting that the overall architecture will evolve; tell the business that "we can't say when it will be ready," but at least they will be able to release incrementally.

This is analogous to driving from New York to Boston by just jumping in the car and driving off in a random direction. ("Hey! That looks interesting.") Don’t worry, we’ll get there eventually, and we’ll take an adaptive route by responding to feedback ("Whoops, wrong way!") as we go.

Now any responsible adult would start by consulting a map, discovering that Boston is roughly northeast of New York along the coast, and determining the outline of a route. A more organized person might know some basic statistics about his car, which would give him an idea of how many fuel stops he should factor in and how long the journey should take. At this point the law of diminishing returns kicks in. He could plan ahead of time where and when he expected to stop, and even in which lanes he was likely to drive. He could take it to an extreme by guessing (sorry, estimating) where and when he might overtake other vehicles or encounter roadblocks.

Once underway, he would want to keep his itinerary up to date. The more detailed the itinerary, the more effort it would take, until he found himself spending more time updating his charts than actually getting anywhere.

Clearly neither of these is ideal. Leaving the house with no planning or analysis might lead you anywhere, driving around lost and hoping for signposts. But too much analyzing and planning carries an unacceptable cost, in both the initial investment and ongoing maintenance of your plans. The answer must lie somewhere in between.

At its most fundamental level, "agile" simply means "able to adapt to change." In fact, when the original members of the Agile Alliance were crafting the Agile Manifesto, the term "adaptive" was proposed as being less ambiguous—especially to non-native English speakers—than the word "agile." Thus, an agile approach to driving from New York to Boston means we should do enough planning and analysis but no more. In this sense, “enough” is a subjective measure that means we feel safe to set off on the journey. Anything more is wasted effort;