Agility Test

You have a mission. Should you accept it, you will report to the shore of a wide but swift river, at night. On this shore is an old paddle-wheel boat. You must get the boat to a location on the far shore. You'll know the location by the landmarks around it, and you know at least that the location is a way downstream from here, but you don't know the exact heading from here to there. You have no electricity, GPS, or maps.

The ship comes with a big steam engine, and a big lamp. The fuel for each is the same; the hold of the ship is full of stacks and stacks of pieces of grey-green paper with little etched pictures of old people on them.

Your goal is to get as much of this paper substance to that location on the other shore as possible. You get points for how close to the goal you land, and how much of the paper you arrive with.

Let's play this like a video game, and give you three chances. So the first time you jump in, you assess the risk of not reaching the far shore as greater than the risk you don't reach the landing point on that shore. As the opposing shore should fall on a line at right angles to this shore, you put paper into the engine and start it, put a little paper in the lamp and light it, and pull the rudder until the ship's heading away from shore.

At first progress appears good. Deciding to get this leg of the trip over faster, you throw a lot more paper into the engine. It roars with power, and the boat slices thru the water.

Progress still appears good.

Progress appears good for a long time. You wonder how far away the shore is.

You throw more paper into the lamp.

It emits more light, and you adjust its lens to focus that light on the path ahead.

Then you see the rocks and shoals and falls up ahead. You have been powering with the current, not across it, and this situation is not in control, it is in entropy.

You throw more paper into the lamp, and yank the rudder hard over to port. Then you discover another thing about boats; the faster you go, the harder it is to turn. You release steam from the engine, close the air vent to the boiler, and stop throwing paper in.

From here, wherever the ship ends up - beached on a shore in the middle of nowhere, or over the falls - you will have used up a whole lot of that paper, possibly all, first by going very fast in the wrong direction, and then thru reckless attempts at recovery.

We will let you hit the Restart button on this video game now. You get the same boat, and you have a second attempt, starting with the same amount of green-grey paper. Tip: real life generally is not recoverable like this (unless your profession is Junior Software Engineer ;-).

Now this second time you set out, you try to think of a better strategy. First you will power the boat for a while, then you will stop the engine and make the light very bright and look around. So you alternate these activities every hour or so.

Funny thing about flowing water - it's very hard to tell when you are going in circles. Here the surface looks like it's flowing, but there it's calm. And chugging at full speed without lights leads to nasty surprises like sharp rocks sticking out of the water...

So this time you alternate power and lights to tell when you are going across the flow. This strategy puts you on a far shore, so now you can turn starboard and seek the landing point. But after all that stopping and starting you don't deliver much of the paper there.

Third time's a charm. If throwing all the paper into the engine did not work, and if alternating looking around with moving took a long time, this time you fire that lamp up as bright as you can make it even before leaving this shore.

Now you see enough of the water to see where the central channel is. When you get to it you are ready. You run the engine at full steam only when fighting real currents. When the water is calm you run the engine slow so that the lamp, at full strength, will show you obstacles in time to steer around them. And you arrive with most of your cargo.

The moral of the story is to devote resources to the lamp, not the engine. Seeing where you are going is more important than going in some direction fast.

A project becomes agile when money committed to the system generates Information about the project's status faster than it generates Thrust pushing the project in a given direction.

 T ****..........*...|
 ......***......*....|
 .........**..**.....|
 ...........**.......|
 .........**..**.....|
 ......***......*....|
 I ****..........*...|
  --------------------

All projects start with a large effort to write something, so the Thrust starts very high and slopes down to horizontal. And all projects start with no feedback, so the rate at which Information becomes useful starts low, curves up, and reaches a high horizontal.

Projects become agile when those lines cross; when Information is gathered at enough rate to steer the Thrust. In our metaphor, the light must be bright enough to see beyond the turning radius of the boat at its current speed.

A WaterFall project leaves the thrust very high and the feedback very low for a long time. The project only becomes steerable after committing a lot of money generating thrust. Then any effort at recovery wastes the money that put the project into the wrong place. The documentation phases do not create information. They create direction that the project must then follow for a long time.

A Spiral project is a series of Waterfalls. So although a project generates information at the end of a cycle and permits steering, the next cycle will start over again with a high Thrust and low Information rate.

To achieve Agility, the Information must be useful. The above chart does not refer to all the information in a project, it refers to the rate at which information reliable enough to steer with appears. The information must be fresh, and grounded in reality.

The Agile Methodologies are the ones that place that crossover point as close as possible to the start of a project. They can do this because the ultimate source of information about a project's true status and location, reliable enough to steer with, is the relentless testing. Only test-infected code can frequently integrate; only integrated code can frequently release, and only released code can create feedback from real users.

-- PhlIp

Although slightly diverging from the intent of this page, I suggest that Agile Methods are proposing much more than very fast waterfalls. The difficulty with the waterfall is that it imposes barriers between the developer and user. A user request has to traverse several steps to get from the user into the code. This not only reduces the speed of the feed back; it also reduces the quantity of the feed back. Compare "I need this fixed." "Is it more important than these other things?" "Yes." "Okay, we'll start on it next week." versus "I need this fixed." "Fill out a request form."

You are totally on track with the page's intent. So I suppose the intent could have been clearer. But the speed of the water towards that fall doesn't change...

I could imagine waterfall people telling a similar story. Only they'd be emphasizing that you need to do a lot of work up-front to find the way. They might even suggest taking short cruises to help develop a map. All software developers admit the value of information. The question is whether you find the information first and then act on it, or whether you have to combine learning and acting. Proponents of agile methods say that you have to combine them, that you can't figure out the way without going along it. Your story doesn't make that as clear as it should. -- RalphJohnson

Recent (April 2003) MicroSoft press advertisements suggest that your company is "agile" just as soon as every information source and tool within it is built on .net