Agile Bridge Building

After yet another session of re-explaining the bleeding obvious to thunderous silence, I decided on a fresh approach.

Commonly, we Agile practitioners start by explaining that software is not like building bridges.  Building bridges is expensive, labour-intensive, and there’s really only one opportunity to get it right.  “Big design up front” is deemed absolutely necessary, even though it doesn’t guarantee a successful outcome.  We might even show them the hilarious (but fake) picture of a bridge that doesn’t line up where it’s supposed to meet.

We then explain that software is mutable (lose 30% of the audience right there), that it’s quick to prototype (another 30%) and that we can easily put those prototypes in front of customers for valuable feedback (and there goes another 30%).  If there’s anyone left by this point (c’mon, I’ve made the maths easy for you!), most of them will only be on side through sheer willing optimism.  If you’re showing amusing cat photos at this point, you’re on the floor.

Ok, this is a deeply pessimistic and cynical view; it doesn’t always go this way.  Some audiences are easier to convince than others.

But, where you anticipate thousand-yard stares, perhaps it would be better to try turning the software-vs-engineering comparison on its head.  What if heavy engineering project benefitted from all the same properties of software?  Take away the restrictions of planning permission, time/material costs, health & safety concerns and, ahem, physics and imagine what you could do.  Please note: you’re going to have to suspend disbelief like never before; stay with me.

Let’s take the example of a bridge that carries cars & lorries across a river.   For such a bridge to be a success, it needs to:

a) be beneficial to motorists (e.g. cutting down journey time)

b) not fall down

I’m not sure whether I got those in the right order, but they’re both important.  Nobody drives across a bridge for the hell of it.  A beautiful but empty bridge is a failure.  (I’m laying on the software metaphor really thick – can you tell?)

So you first want to test out the usefulness of your bridge.  We have several potential crossing places, so let’s whittle those down as best we can to the ones we think will be most viable, and then build a test bridge across just one.  We do this knowing that we’re not going to send lorries across it, but also making sure we don’t rule it out.  Now we send some cars across it.  We drive across it ourselves, of course, but there’s nothing like getting some friends and colleagues to try it out also.  Bridge still standing?  Ok, let’s open it up to the public – cars only and we carefully monitor the bridge’s stability.  If this is ever in doubt, we can throttle back the traffic allowed to cross it.

So, is the bridge useful?  Does it alleviate traffic congestion, cut down journey times?  If not, then we simply move our bridge to one of the other viable crossing points and re-open to the public.  Our bridge is inherently flexible in that way (but hopefully not in any other way).

While all this testing is going on, we’re designing bridge v2, which will take lorries.  We take a carbon copy of bridge v1 out into the desert, drive lorries across it, and watch it break.  And, more importantly, watch *when and where* it breaks.  We use this information, along with our knowledge of structural design to determine how and where the bridge needs to be enhanced.  We build those enhancements, regularly driving lorries across, until we’ve got it right.  Or more accurately, until we’re confident that we can open to the public without hitting the 6 o’clock news.  Ok, physicists cover your ears, because we teleport the new bridge into place on top of the old bridge, simultaneously teleporting the old bridge out… all with traffic driving across it.  And then we invite the lorries to cross.

Now we have a bridge that’s generally fit-for-purpose, and in only 2 sprints!  Anything beyond this is an embellishment… be it new features, flashy embellishments.  But all the while we’re adding those changes, we’re getting feedback from motorists and from our stunt drivers to make sure we’re not doing anything to harm the basic 6-o’clock-news-avoiding features of the bridge.

We’d build bridges a lot quicker this way, but we’d also build many more bridges than we currently do.  And you’d probably find bridges being used to solve problems in places where people had previously not dared.

I’ve said “bridges” too much now, and stretched my analogy to breaking point.  Is that the sound of thunderous silence I hear?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: