Bridge metaphors seem to be unavoidable when talking about agile vs waterfall software development. There’s something irresistible about comparing intangible software with solid concrete and steel rods.
A grizzly (in both experience and character) old colleague of mine used to relish in explaining how there was value in planning, designing and procuring all aspects of physical engineering projects up front. He’d tell his audience about how you could reliably model your structure’s performance with just pencils, paper and a calculator, and be confident in its robustness before it was even built.
Software, he said, was different because the best way to design a software system is to build it. There is no cheaper, or more effective method of representing and validating software than with code. As such, all design activities that don’t result in working code are wasteful. You might as well just build the thing.
Aside from the obvious oversimplifications, for the most part, I don’t disagree with him. Giving users working software is undeniably the best way to prove your software works for users. I don’t, however, think this metaphor is actually particularly useful in the real world. Unless you have a lot of pre-existing trust and/or credibility, telling someone who has time and money on the line that you don’t know what you’ll give them at the end of their time and money is a surefire way to set alarm bells ringing.
This is fair enough. Too often in our industry people have conflated agile with not having a plan. This invariably leads to lost time and money, and stakeholders who become entrenched in heavy processes that help them feel like they have a handle on risk because they “tried agile once and it didn’t really work”.
This bridge metaphor also fails to capture the central benefit and idea of agile practices - the ability to adapt to change. I have a different bridge metaphor that I think captures this better, and explains how you’re going deliver worthwhile outcomes from someone’s investment of time and money in you. It also demonstrates how, by relinquishing some control and allowing processes to be more flexible, stakeholders can actually reduce the risk of projects spinning out of control.
The idea is this: you should build your bridges out of bamboo and string.
Your users have a problem that they need solving. As they stare down the giant gorge they tell you that they want to get to the other side. They have money, and they will pay you to build a bridge. At this point you have some options:
- You could get out your pencil, paper and calculator and start furiously drawing up plans, telling your users that you expect to give them a fantastically strong bridge in a few years time (barring any unforeseen events that halt construction).
- You could roll up your sleeves and start pouring concrete right away. You promise your users that things are going in the right direction, give them regular updates and invite them test parts of the bridge as it’s built to make sure that they’ve happy with it.
- You could tie together a few bamboo poles to span the gap, and invite your users to balance across.
Option one is obviously the classic waterfall approach that people love to berate. I think most people who believe themselves to be agile these days would pick option two. It sounds sensible, and with an experienced team to build it you may well end up with a functioning bridge faster than you would have if you designed the whole thing up front. With all the testing and user feedback it certainly sounds like an agile approach but is it really?