During a leadership peer-to-peer session, we recently discussed the planning and execution of software projects and how the term “Agile” has become a running joke within some technology teams. This is largely due to its misuse in larger corporations as they attempt to shoehorn existing processes and culture into a state suitable for modern business rather than by taking a holistic approach that starts by fostering the correct culture. Throwing the word “Agile” off the cuff is now the equivalent of walking into a guitar store and playing Stairway to Heaven.
Our conversation explored why this tends to happen, the unique nature of software development, and how taking an agile approach depends on the nature of the project or business. We all agreed that the prerequisite for an Agile approach is “unknown” or “changing requirements”, - but if those requirements are static, Agile might not be what you need.
One analogy we discussed was that of building a bridge across a river. For instance, a plank of wood spanning across is technically a bridge, and while it may not support cars driving over it, it's the minimum viable solution to be classed as a bridge. In contrast, the Golden Gate Bridge, completed in 1937, is a moonshot example that has stood the test of time. The effort required to create both solutions varies greatly, as does their delivery speed and longevity.
When building a physical bridge, the requirements (such as the number of lanes or traffic capacity) and landscape are known well before work begins, calculations are done, and structural viability is carried out. However, requirements, including the technology “landscape”, can change when developing software, forcing us to re-visit everything we know and have developed thus far. While the Golden Gate Bridge analogy resonated with the group, on reflection, it didn't quite capture the essence of developing on the “unknown”. To me, agile software development is akin to the Channel Tunnel that connects the United Kingdom with France.
So, in my research this week, I went down a rabbit hole into the boring history of achieving this remarkable feat of engineering. The mission to conquer this 21-mile stretch of undersea tunnelling is a perfect Agile engineering example.
A History of the Channel Tunnel
First Ideas
Although disputed due to the lack of tangible evidence, Nicholas Demorest made the first proposal for a channel crossing in 1750.
However, without actual plans in the history books, we can jump to 1802, when Frenchman Albert Mathieu Favier proposed his version of a crossing. This pre-industrial revolution idea was one of two tunnels, one for horse and cart and the other for drainage. This tunnel was to have ventilation shafts rising from the sea and an artificial island as a halfway rest point for travellers. Unfortunately, none of this work ever started because of the Napoleonic Wars.
An Aerostatic imagination
We have Monsieur Ferdinand Le Mantra to thank for his imaginative idea in the 1850s, proposing an "Aerostatic bridge" across the channel. Imagine a heavily laden barge connected to double iron chains attached to a balloon supporting a bridge every 100 yards. It sounds ridiculous today, but it was considered a serious idea worth exploring at the time - "Imagine that first gust of wind.”
A Feasible Solution
In 1856, Tom de Gammond presented his idea of a mined tunnel, which Napoleon III and Queen Victoria initially accepted. However, after an attempt on Napoleon's life in 1858, he cancelled the plans because a group in the UK manufactured the bombs used in the attack.
The First Attempt
Fast-forward 20 years, and new rail technology is starting to cover the UK. A group of French and British engineers proposed an underground railroad, and each began to bore test tunnels on their respective sides of the channel. Despite initial enthusiasm and good progress from both parties, the project once again encountered political tensions and was eventually abandoned.
The Second Attempt
Following the UK's entrance into the European Union, the French and British governments supported another attempt to complete the tunnel. Construction started in 1974 and continued for two years before the project was abandoned due to financial difficulties and boring technology problems.
Back to the drawing board
Detailed plans for a 21-mile toll bridge suspended at 67m were submitted to Margaret Thatcher’s government in the late 1980s. Though it isn’t clear what the government's response to these proposals was, the fact that the channel was now one of the busiest shipping lanes in the world probably made a bridge unfeasible.
Third Times a Charm
It wasn't until 1988 that the successful Channel Tunnel project began. The design called for two 32-mile-long rail tunnels and a smaller service tunnel running between them. The construction process was an engineering marvel, using massive tunnel boring machines to dig through the chalk and clay beneath the seabed to meet in the middle.
The Channel Tunnel was eventually opened in 1994 and has allowed over 185 million passengers to travel between the UK and France to date.
In conclusion, the Channel Tunnel project reminds us that great achievements often come with significant challenges, especially when digging in the dark. As technology leaders in software development, we can use examples from outside our domain to draw valuable lessons and paint a clearer picture.
The next time you find yourself in the trenches of an Agile project, remember the determination and invention that brought the Channel Tunnel to life. After all, sometimes, the most boring projects can lead to the most exciting breakthroughs.