bamboo bridge Photo by Ashwin Kumar on flickr

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:

  1. 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).
  2. 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.
  3. 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? If you’re not careful you might find yourself in a position where your structure spans half the gorge but for one reason or another you discover that it’s not going to make it all the way. You feel like you did all the right things, you broke the problem up into short five metre chunks which you could realistically commit to completing every couple of weeks. ‘Users’ would walk out on the bridge right up to the edge and tell you that it felt pretty stable so far, and they were happy with the direction it was pointing.

One day, however, you start to notice cracks and they seem to be growing with every metre you add to the bridge. Everyone agrees that fixing the cracks is a priority so you begin to focus on that. It seems like there are probably two viable approaches. You could either tear the whole thing down and start again in the hopes that you can work out how to make sure there are no cracks this time. Alternatively you could try and secure the cracks with big steel straps and rivets. Neither option is particularly appealing You’ve spent a lot of money on concrete already and it will time consuming and expensive the break up and remove it. The steel straps are cheaper and will let you keep building the bridge in the right direction. Your team opts for the latter and it feels like the right decision. You start making progress again until you discover that the rivets you used to install the straps are sheering off when the wind blows a certain direction. You add more straps to reduce the strain on the current ones and before you know it, almost all your focus is on working out where the next strap needs to be placed in order to keep the whole structure upright. The bridge is ugly, people keep tripping over straps, and now it takes weeks to extend the bridge just a few centimeters because you have to work around all the awkwardly placed straps.

This is the kind of experience that leads to people saying things like “Agile is great in theory, but really you should just do waterfall” (as if doing waterfall was an actual defined process itself). They’ve been burned by projects that started well but amassed tech debt and struggled to manage it in a way that enabled them easily continue delivering useful features to their users. I think a lot of teams get themselves into this position without even realising it’s happened. They assume that this is just the reality of software development, and maybe, with some luck next time will be better. Complexity is insidious, and I think we condition ourselves to accept far more of it than is strictly necessary. Instead of starting construction of your bridge with steel and concrete you should begin with bamboo and string.

Some engineers might scoff at this. They’ll tell you that bamboo and string isn’t strong enough, it won’t last and that you should build a ‘proper bridge’ using ‘proper materials’ like the concrete and steel 99% of other bridges are built with. Maybe the bamboo and string aren’t as strong, and as resiliant as the concrete and steel. But maybe it’s just strong enough to do what you need right now. You lash some poles together and lay them across the gorge in the space of a day. It’s very bendy, and the risk of falling off is pretty real but there is now at least a way to cross the gorge. If the need for this crossing is great enough then people will brave the risks and make use of it. There aren’t very many of them but the fact that some do cross tells you on the right track.

[…TBC…]