"Once I built a railroad, now it's done
 Brother, can you spare a dime?"

A couple of evenings ago at the monthly meeting o Agile RTP Jason Tanner from Enthiosys led a discussion of experience in introducing agile development methods to companies.

He led off by encouraging the audience to make index cards inscribed with impediments to the adoption of agile methods which the attendee had encountered, and tape them to a whiteboard. He then took the cards off and discussed them.

One of the first was something like, “people who can’t work without a detailed long-range plan.”

For some, reason, the old depression-era song “Brother can you spare a dime?” popped into my head as soon as that discussion started.

Planes, Trains, and Automobiles

Kent Beck tells the story in Extreme Programming Explained: Embrace Change (2nd Edition) (XP Series) about his first lesson on driving a car, given by his mother. She started by giving him a feel for the steering wheel, by having him reach across from the passenger seat and take the wheel and see how it affected the direction of the car. She then told him to look ahead and point the car down the road. After a while, is attention drifted a bit and the car started towards the gravel at the side of the road. Kent’s mom gently took control back and gave him his first real driving lesson:

"Driving is not about getting the car going in the right direction. Driving is about constantly paying attention,
 making a little correction this way, a little correction that way."

To me that’s the real difference between agile and waterfall approaches.

The waterfall “tradition” attempts to avoid getting off the road by starting out with a plan. If it works the plan is like a set of railroad tracks which forces the train to always go in the right direction. The engineer doesn’t need to pay as much attention.

Agile methods are much more like driving, setting a general short term direction, with the current long term goal in mind, and reacting to feedback so that constant correction keeps the project from going into the ditch. At a more mature level, it becomes more like flying a plane, which is like driving a car, but with more complex feedback-control relationships and in three dimensions rather than two.

The Problem with Tracks

A railroad is a great thing as long as it goes where you really need to go. But getting on the wrong train can be a costly mistake. You can end up traveling a long way away from your goal, and waste a lot of time in the error and in recovering from the error.

You might enjoy the scenery along the way, thinking you are progressing towards your goal, until you realize your mistake. This is a great metaphor for some of the waterfall projects which I’ve seen go astray. Of course those projects suffer the expense not just of riding the wrong train, but of designing and building the railroad through a process of design based on incompletely understood requirements.

As Yogi Berra said, “If you don’t know where you are going, you’ll end up somewhere else.” And all too often in developing software, we don’t really know where we are going except in a general or vague sense. Requirements based on this level of understanding are fragile in the face of knowledge gained about the problem context and about the solution as development proceeds. If you are riding the train, you might start to get a sense that you might not be where you need to be gradually, an increasing unease perhaps rising to panic.

If you are on the wrong track, you can end up wasting lots of time and lots of dimes!

I’ve found that it’s much better to file a flight plan, then react to changing weather, input from flight controllers, and radio instructions from “the home office” when business plans change and I now need to get to Chicago instead of St. Louis.

And that’s why that song popped into my head, I was thinking:

Once I built a railroad, but it went to the wrong place.