Building Bridges with Agile: Why It's Not as Simple as Crossing the River

Imagine you're standing on one bank of a river, looking across to the other side. You have a grand vision of a bridge that connects the two banks, facilitating travel, commerce, and community. As you stand there, you wonder: could we use Agile methodologies to build this bridge? After all, Agile has revolutionised software development with its promises of flexibility, speed, and customer satisfaction. Why not give it a shot?

Before we lay the first plank, let's start with a quick primer on Agile. Born from the frustrations of rigid, bureaucratic software development practices, Agile emerged as a refreshing alternative. Agile emphasises adaptability, collaboration, and delivering small, incremental pieces of functionality over time. It’s all about being nimble, responding to change, and putting the customer's needs at the heart of the process. The Agile Manifesto, penned in 2001, laid out four core values:

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Sounds brilliant for software, doesn't it? Now, let's translate this to the business of building bridges—a task that, unlike software, deals with gravity, physics, and the inconvenient reality of large bodies of water.

Working Hardware Over Comprehensive Documentation?

In Agile, there's a preference for working software over comprehensive documentation. Swap "software" for "hardware," and you might picture a half-built bridge, swaying precariously in the breeze as engineers debate the next iteration over a cup of tea. The catch? Bridges don’t respond well to 'working hardware' without comprehensive documentation.

You can't just decide to skip over the blueprints and hope for the best. There's no MVP (Minimum Viable Product) version of a bridge—half a bridge doesn’t really cut it. The structural integrity must be meticulously planned out, documented, and reviewed before a single rivet is hammered into place. An Agile approach might favour starting with the simplest version of a bridge and improving it over time. But try telling that to the commuter standing at the edge of an incomplete structure, staring nervously at the gap over the river. "Mind the gap!" takes on a whole new meaning when you're staring at a yawning chasm where the rest of your bridge should be.

Imagine the conversation:

Engineer: "Right, we've built half the bridge. Fancy giving it a go?"

Commuter: "Erm... I think I'll take the ferry, thanks."

Individuals and Interactions Over Processes and Tools

Agile champions the power of individuals and interactions. Teams are encouraged to be self-organising, finding the best way to work together without being tied down by rigid processes or specific tools. Imagine this in a bridge-building scenario: "Right, lads, use whatever hammer feels good in your hand, and we'll just see how it goes!"

While the image of empowered individuals is charming, bridge building is a bit more of a serious business. Processes and tools exist for a reason. The architects, engineers, and foremen have spent years learning and honing their craft. They rely on established processes to ensure that every piece fits perfectly, every bolt is tightened to the exact specification, and every beam supports the intended load. A bridge isn't just a collaborative art project; it's a feat of engineering precision. Deviation from the established process isn't just discouraged; it’s potentially disastrous.

Picture this scene: Foreman: "Right lads, use whatever tool feels good in your hands. Bob, if you fancy using that rubber mallet for driving in rivets, who am I to stop you? And Dave, if you want to eyeball those measurements instead of using a laser level, go right ahead!"

Customer Collaboration Over Contract Negotiation

In Agile, the customer is king, and collaboration is key. However, in bridge-building, things are slightly different. The contract for a bridge is typically negotiated, estimated, and sealed before the first shovel hits the ground. Sure, there might be discussions with stakeholders—local governments, transport authorities, and funding bodies—but once the contract is signed, the project has a clear scope and budget.

Now, imagine taking a purely Agile approach: "We’ve decided to change the design halfway through; it’s now going to be a suspension bridge instead of a beam bridge. How does that sound?" The response from the project sponsor would likely be less than enthusiastic. The commuters, the real end-users of the bridge, might have preferences—less traffic, shorter travel times—but their involvement in the design process is, at best, indirect. They certainly aren't consulted about whether the bridge should have decorative railings or be painted a particular shade of blue.

Local Resident: "You know what this bridge needs? A nice water slide on the side. For the kids, you understand."

Project Manager: muffled screams

Responding to Change Over Following a Plan

This is where Agile really shines: the ability to pivot, to change course in response to new information or circumstances. But even in bridge-building, where plans must be followed rigorously, unexpected events do occur. The construction team might encounter unstable soil or hidden boulders, requiring immediate remediation.

But here’s the rub: remediation in construction is not the same as Agile’s responsiveness. It’s not about changing the end product; it’s about adjusting the method to achieve the same planned outcome. The plans are adapted, yes, but they are adapted by experts who know precisely how to respond to these challenges. The end goal remains a safe, functional bridge—not a new iteration of the product based on feedback from the river.

Consider the all-too-common scenario on large construction projects: the materials ordered aren't always the materials received. Imagine eagerly awaiting a shipment of high-grade steel beams, specified for their load-bearing capabilities, only to find that what’s delivered is a batch of standard-grade steel, or worse, aluminium. Now, in the Agile world, you might simply "respond to change" and start using what's on hand. After all, you’ve got a schedule to keep, right?

Wrong. In bridge-building, you can’t just swap out materials and hope for the best. Every component has specific engineering requirements—those high-grade steel beams were specified for a reason. An engineering review is needed to determine whether the new materials are still structurally sound. If not, all work in that section of the bridge must come to a grinding halt until suitable materials are found. And that’s not just a minor inconvenience; it can have major downstream dependencies.

In some cases, the crew might be able to work on other, non-dependent parts of the bridge while waiting for the correct materials, making the best of a bad situation. But in other cases, this material swap could hit a critical path—meaning no further progress can be made on the bridge until the issue is resolved. It’s not about being inflexible; it’s about ensuring that every part of the bridge meets the stringent safety and performance standards required to support the weight of thousands of vehicles every day.

So, while Agile might suggest "responding to change" as an inherent good, bridge-building requires a more nuanced approach. Changes and unforeseen issues must be managed within the strict confines of engineering principles and safety regulations, not through quick fixes or improvised solutions that might work in more flexible industries. When it comes to the safety and reliability of a bridge, it’s not about 'responding to change'—it’s about responding correctly, with thorough analysis and expert judgment, ensuring that every change still leads to the same end: a bridge that safely connects one side to the other.

Agile’s strengths lie in its adaptability and speed, but in the world of bridges, precision, planning, and safety take precedence. As exciting as Agile’s adaptability might seem, when you’re building something that hundreds or thousands of people will depend on daily, sometimes a slower, more measured response is the only responsible choice.

Contractor: "So, I was thinking... what if we made this a suspension bridge instead of a beam bridge?"

Engineer: "We're halfway through construction."

Contractor: "Yeah, but think how cool it would look!"

Engineer: quietly updates CV

Agile’s Iterative Process Meets Engineering Reality

Agile thrives on iterations, sprints, and feedback loops. Software development benefits from this approach because software is malleable—features can be added, removed, or altered with relative ease. Bridges, however, are stubbornly physical. You can't just 'refactor' a bridge if the initial design turns out to be less than optimal. Once the concrete is poured, changing your mind becomes a bit more, shall we say, concrete.

Bridge-building teams are composed of specialists, each with a critical role. There's little room for a Scrum Master cheerfully guiding the team through daily stand-ups, discussing yesterday’s achievements of laying down the foundation and today’s goal of ‘just seeing where the morning takes us.’ These teams operate on precise schedules, where each phase of construction relies on the successful completion of the last, adhering to well-defined plans that have been scrutinised by a small army of engineers.

Minimum Viable Product? Not in Bridge Building

One of Agile’s favourite concepts is the MVP—the Minimum Viable Product. The idea is to deliver the simplest version of a product that can be released to users, and then build upon it based on feedback. In bridge-building, however, there’s no such thing as an MVP. You don’t get to build half a bridge and ask the public to test it out.

“Here’s the minimum viable bridge, folks! Just take a running start and mind the gap!”

Somehow, I doubt that would pass the health and safety inspections.

Conclusion: Building Bridges, Not Agile Ideals

Agile has its place, and that place is where flexibility, iteration, and customer collaboration can thrive. In software, in marketing, even in creative industries, Agile provides a framework for managing uncertainty and embracing change. But in bridge-building, where the stakes are high, the risks are real, and the consequences of failure are catastrophic, a different approach is needed.

Bridges demand careful planning, adherence to strict standards, and rigorous documentation. They are the physical embodiments of careful thought, precise execution, and tested knowledge. So, while Agile has transformed the way many industries work, some projects—like building bridges—are better left to the engineers who have been perfecting their craft since the days of Ancient Rome, long before anyone thought to put “Agile” on the project charter.

Sometimes, it’s best to stick to the plan and let the bridge do what bridges do best: provide a safe, reliable crossing from one side to the other. And that’s a pretty solid outcome, by any methodology’s standards.