Consider the Titanic.
Based on entire minutes spent Googling, it appears the ship’s lookout spotted the iceberg that sank the ship when it was about 2,000 feet away. This seems like plenty of time to steer around a hazard, and it would have been plenty of time — at 20 knots, almost a full minute — had the Titanic been, say, a fishing trawler.
It wasn’t. It was the biggest ocean liner of its day, and even with a rudder 78 feet 8 inches high and 15 feet 3 inches long, its turning radius at full speed was about 1,900 feet.
1,900 feet being a shorter distance than 2,000 feet, it appears there was enough room for the Titanic to miss the iceberg. But history and John Cameron tell us it didn’t miss.
What went wrong? It turns out the decision as to whether to steer around the hazard or to maintain course turns out to have been quite a bit more complicated than hindsight makes it appear. If this makes no sense to you: The ship might have missed the iceberg, which was after all in motion, by maintaining course; trying to steer around the iceberg might have resulted in impact closer to the stern, doing more damage; reducing engine power to reduce speed would have reduced the rudder’s effectiveness, to name three complications among many.
In the end it was a judgment call that took 37 seconds to make — enough time for the Titanic to have missed the iceberg. If you’re interested, read “The 30 seconds that sank the Titanic — fatal delay in order to change course doomed liner,” Jasper Copping, Daily Telegraph, 12/4/2011.)
Which has what to do with the worlds of IT, business, and their intersection?
Start with 20/20 hindsight. I’m assigning you the mission to allocate blame … sorry, to determine the root cause. You start with the most basic question: Was the problem that the ship’s turning radius was too big, or that it took too long to decide to change course?
The answer is, of course, yes.
And now (at last!) we’re ready for business, IT, decision-making, and all things Agile.
As we all know, IT has to adopt Agile. If you don’t use Agile techniques by now you’re two hops short of current thinking, current thinking having moved to DevOps, which is itself a hop short of what’s actually needed.
Among Agile’s many benefits compared to Waterfall alternatives are two sides of one coin that gets far too little attention.
Side 1 is Agile’s ability to reduce the damage done by the management fad du jour.
Something largely unappreciated about fads du jour is that in the eyes of the managers who sponsor them they aren’t fads at all. They’re responses to important business trends, marketplace shifts, new and better thinking … that sort of thing. But time passes, sponsors move on or lose influence, gratification is less than instantaneous, and the executive leadership team (ELT) moves on to whatever is next in queue.
But in the meantime, through various governance mechanisms rooted in Waterfall-based assumptions about how much time and investment is needed to make change happen, a very large fraction of the company’s total discretionary budget is directed to turn the fad du jour into operating business reality.
Which in turn makes it unavailable for other, more valuable but less strategic uses for timescales measured in years.
With Agile techniques, companies can slow down or stop business change efforts sooner and still get some value out of them because Agile delivers working stuff in timescales measured in weeks (sprints), and tangible business change in months (releases).
One of Agile’s most important characteristics is a governance mechanism that, depending which Agile variant you use, changes priorities dynamically in these same timescales.
Which in turn means fads du jour‘s resource commitments don’t have to be any longer than this.
Side 2 is the exact same thing, only instead of mitigating the damage done by fads du jour draining resources away from higher-value efforts, it accelerates the value provided by projects that with Agile deliver business change in months instead of years.
In Titanic Governance terms, it means decisions about how best to avoid various business icebergs can be made faster and changed faster.
While it’s stretching the metaphor just a bit, Agile itself is parallel to reducing the Titanic’s turning radius. Agile Governance, done right, decides to turn to avoid the iceberg faster.
Done wrong, the same old governance, unconsciously based on the same old Waterfall assumptions, can crash even the best Agile project practices right into the same old decision-delay icebergs.
Bob,
Think you might have missed on this one. The answer(or at least one answer) is that the Titanic was going too fast.
Peace, J
Maybe, but then, with bad enough decisions, no speed is safe.
Thought provoking analogy!
I think you meant James Cameron, rather than John.
Jim Devaney’s point is sound. If the ship was traveling at a speed where it could not reasonably avoid or mitigate a foreseeable disaster using its known processes, it was operating recklessly. The problem is not that with bad decisions, no speed is safe, it’s that even with good decisions, the speed that had been chosen was not safe.
This leaves an open question: What was the minimum iceberg detection distance when sailing at night in 1912? I suspect this is a question nobody in 1912 could have answered with any level of accuracy. Without that information there was no way to calculate what a safe speed might have been.
It’s also worth pointing out that in the decade preceding the Titanic disaster there were a total of 3 ships that collided with icebergs. I couldn’t find a statistic of total number of Atlantic crossings per year. If we assume even 10 ships with a one-week crossing time per ship, that would suggest 500 crossings per year, meaning the risk of a collision would have been about 3/5,000. The risk of sinking would have been far lower.
I have a hard time faulting the company for sailing at top speed.
To my way of thinking, to the extent the disaster was anyone’s fault it was the design decision to have too few lifeboats to accommodate the full complement of passengers and crew. Even here, the Titanic was in compliance with regulations (or so I’ve read). I’m guessing that, then as now, once you have a compliance checkbox your job is done when you can check it off.
I think the biggest benefit of Agile is its ability to deliver a product before the user can change their minds.
As far as turning the Titanic, I like the analogy.
I loved the article, too. Especially how the Board of Inquiry completely discounted the testimony of sailors and only believed officers. Fortunately, that doesn’t happen in companies nowadays.
Extending the analogy, the latest findings are that a coal fire weakened the steel hull of the Titanic. The fire was going when they left port but they couldn’t not leave because the had a hard release date what with all the paying passengers and world-wide publicity. Fortunately, that doesn’t happen in companies nowadays either.
Interestingly enough (and complete apart from your Agile analogy), there’s pretty good evidence that the Titanic would have been better off not turning and instead striking the iceberg directly. Doing so would probably have limited the structural damage to the first watertight compartment, and the Titanic would have remained seaworthy. Because of the attempted turn, she instead sideswiped the iceberg and tore open five of her sixteen watertight compartments, too many to remain afloat.
I like the analogy of agile as the turn radius as this dovetails nicely with agile being in important component in shrinking an organization’s OODA loop. The tighter the turn, the faster to market.
A different analysis I read (but don’t remember the source) is that the Titanic was rushed into service without fully conducting speed trials, so that for instance the deck officer had no way to know if full rudder at full speed made a faster turn than say backing one propeller full speed while leaving the opposite side full ahead.
And remember that 7/8 of the iceberg is below water so there could have been part sticking out unseen.
Lastly, backing all propellers full and hitting the iceberg full on is generally thought of as saving the ship because fewer compartments would be breached. {Time for a “full speed ahead” article?}