The Rise And Fall Of Complexity: The Development Process
[For earlier posts in this series, click here, here, and here.]
Imagine yourself back in childhood, sitting in the back seat of the family station wagon, en route to one of those long, high-stress family vacations that Americans have honed to perfection. Mom and Dad are arguing over what went wrong so far on the trip, and of course, how they could have avoided these mishaps. Why didn't we ask for directions at the last gas station, instead of letting Dad navigate by dead reckoning? Should someone have called ahead to ensure that there wasn't a problem with the hotel reservations? Who was supposed to remember to pack the camera? Was it reasonable to expect a travel rate of 500 miles a day? Quickly, your vision of vacation as a straight line into the heart of fun evaporates. Replacing it is a circuitous flowchart, each serpentine twist representing a different set of decision points, estimates, and possible outcomes. Who knows what might happen next? The wheels will fall off on a desert highway, and someone will have forgotten to renew the AAA membership?
Moving quickly from point A to point B is always desirable. However, even if you replaced the station wagon with a souped-up sports car, the road ahead may still be full of potholes. If you plan your vacation so that you have just enough time, and just enough money, to get to Wally World and back, chances are that something will go wrong, wrecking those plans. The longer the journey, the more opportunities for hitting one of those potholes. (By the way, the power that misfortune has to wreck complex plans is well known and even has a very evocative term: friction.)
Enforced simplicity is one of the chief attractions of Agile, as we've discovered from our surveys of people who have adopted it. During a four-week sprint, you'll run into at least a few minor problems. Maybe you'll run into unexpected performance bottlenecks, or the sainted Voice Of The Customer says that your UI stinks. As unattractive as these possibilities may be, there will be fewer of them in a four-week sprint than a year-long release cycle. By keeping iterations short, Agile reduces the complexity of the final deliverable. The simpler the deliverable, the fewer elements that can go wrong, which has the added benefit of making plans and estimates more accurate.
Adaptability is a crucial benefit of Agile across multiple iterations, not just within a single iteration. A software vendor might still release a major version of a product only once per year. Under the rules of Waterfall, the closer you get to the release date, the more unexpected problems appear, jeopardizing the release date. Eventually, getting the release out the door can take precedence over all issues. Unfortunately, the cost of failing to respond to some of those issues – shifting customer priorities, new competitive threats, poor usability, etc. – can be quite high. Nevertheless, the development engine, straining as it drags its heavy workload forward through months of development, must reach the finish line.
Adaptability isn't the only benefit, beyond velocity, that Agile teams value. Across multiple surveys, Agilists have cited adaptability, predictability, quality, and business/IT alignment as important as speed, and in some cases, more so. Reducing the complexity of the deliverable, by pruning the number of projects down to what can be accomplished within a short sprint, changes the entire development process.
Reducing the size of each iteration has its potential downsides. Long pole projects, compliance documentation, the pressures of constant activity, deep architectural questions – these are just a few of the challenges that newly Agile teams often address. However, this is a trade-off that, if successful with Agile, they'd gladly make. They've been trapped in the back seat of the development process as the grown-ups argued over a plan that was too way complex to succeed.