Random Stew It seemed like a good idea at the time.

Chinese Water Torture

Drip, drip, drip, drip.

Let's take a road trip. I want you to drive me to California from South Carolina, but I'm not sure exactly where in California, just somewhere in the southern part of the state. I'll know it's the right spot when we get there. I need you to provide me with an extremely detailed itinerary, specifying the exact time and location of waypoints along the route. And you must provide this itinerary by merely consulting a map, you cannot check weather or traffic conditions. In fact, you're not quite sure when we'll be making the trip, so you can't even take into account the season. Now imagine we'll be using a bus on this trip, and all the passengers will be giving you directions and asking for stops along the way -- but you're not allowed to talk to these passengers before the trip. I still need you to provide a firm timetable and cost estimate for this trip.

This hypothetical trip is an example of a wicked problem - a problem whose requirements and limitations cannot be entirely known before completion.

Drip, drip, drip, drip.

Three weeks ago, my company was presented with a small project that we estimated would take about a man-month to perform. Since that time, we have met with the Business Analyst (BA) on the project three more times, and each time, the requirements have changed and we've been asked to re-estimate the project. Moreover, with each estimate, we're asked to provide more detail and clarification. We have had no direct contact with the ultimate users of the proposed system. During this time, the BA has produced a few versions of a very nice requirements document, but right now, the customer has no working software. Instead, the project is going through an endless loop of analysis paralysis.

If the project had kicked off three weeks ago, it would likely be complete by now. The customer could be using the software and providing feedback to the development team so that the software could be further refined to solve the users' particular and unique needs.

Drip, drip, drip, drip.

This situation is the inevitable result of the use of the waterfall project management methodology. The benefits of working software are being sacrificed for the illusion of control. I view this as shooting a bullet at the moon; if your assumptions, calculations, and aim are absolutely perfect -- and no unforeseen circumstances occur -- it just might work. But wouldn't it be better to embrace change? To build flexibility into your methodology to accommodate change, mistakes, and unforeseen circumstances? Wouldn't it be better to pilot a projectile to the moon?

To go back to our California trip analogy, instead of creating an extremely detailed itinerary, why not create a general overall goal and timetable with smaller chunks of milestones. For instance, let's just say our target for the first day is to reach Jackson, Mississippi and spend the night there; we'll cover a good amount of ground, but we'll allow for a bit of time to deal with traffic in Atlanta and maybe a bit of weather near Birmingham, Alabama. We anticipate arriving in Jackson in time for dinner, but if we decide as a group to take a detour to see Stone Mountain outside of Atlanta, we won't stress about arriving a bit later in Jackson. Conversely, we may breeze through Atlanta and arrive in Jackson in early afternoon. If so, we may decide to keep going and perhaps stay overnight in Vicksburg, overlooking the Mississippi River.

But we will have a goal of getting to California. We will have a general strategy (itinerary) developed from maps and previous experience. And we will have a set of tactics to deal with unforeseen circumstances. Some of those tactics may be mitigating the risk and impact of unforeseen challenges by carrying extra maps or a GPS, cell phones for communication, credit cards for ready access to cash, and most importantly an adventurous attitude willing to embrace change.

The point being that we will drive "within our headlights". We will set short, reasonable goals that we can accurately predict and work to achieve those goals daily. If any of those goals are not met for some reason, they are reassessed and tomorrow's goals may be adjusted -- perhaps we won't be able to go see the world's biggest ball of string tomorrow. Who knows, with a more relaxed atmosphere on the bus, everyone might even enjoy the trip.

As stated in the Principles of the Agile Manifesto for Software Development, working software is the primary measure of progress.

Instead I'm reviewing yet another change in the requirements documentation. Three weeks of "planning" and "nailing down requirements" for a 4 week project.

Drip, drip, drip, drip.