This was a new route, expected to bring in millions of revenue over the next five years. The aeroplane was brand new and the crew worked together for the first time so some minor problems were expected on this flight, but nobody expected anything serious. Everything was going according to the plan until two hours before the scheduled landing. The copilot suddenly realised that there is no chance to arrive on time as scheduled. Even worse, they would run out of fuel in the middle of the ocean. The pilot called the crew to assemble, at the same time giving a reassuring statement on the PA system in order not to cause panic among the passengers. Panic is, however, exactly the right word to describe the behaviour of the crew once they realised what had happened. The pilot had an idea that could work. It would be tough but they will get everyone down alive. After a quick vote, they decided to give it a go. Another reassuring statement on the PA system explained that the crew has to jettison the luggage to make the aeroplane just lighter enough to reach land. The copilot got in touch with the air traffic control on the continent. Understanding how serious the situation is, they started looking for the closest airport, air strip or even a flat long piece of land where they could possibly land this thing now. Ninety minutes and several confusing messages on the PA system later, the aeroplane was firmly on the ground. The passengers found themselves about 500 miles away from where they were supposed to land and their luggage was now touching the ocean floor. They were however all alive, which was the most important thing anyway. The air traffic control issued a statement praising the pilot and the rest of the crew and their handling of the situation.
Now think about this:
Were the pilot and the crew heroes – or were they a bunch of incompetent idiots?
How does your answer change if the same thing happened again next week and the week after?
At the OpenVolcano10 conference last month, we ended up discussing several examples of software delivery teams in large companies, where this behaviour is not just tolerated but even encouraged. Management praises people and teams that help avert disasters without considering that these same people are the causes of those disasters in the first place. Teams that deliver on schedule and what was expected without much fuss and noise are told to work harder and their projects dismissed as overly simplistic, although the same rewrite effort failed miserably several times before in one case.
I must admit I’ve been blessed so far to run into a similar situation only once, and I left when I realised what is going on to help more sensible people deliver. Most teams and management I worked with actually appreciate the fact that the noise and delivery troubles go away.
What are your experiences? How common is this in the industry? If you have trouble communicating the value of reliable delivery without much noise upstream, what do you think is the problem? How do we make people sitting above the teams in organisational charts see that?
|
|
I’ve also had bad experiences with softwares deliveries. In my case, the problems always caused by lack of automation. Management (at all levels) didn’t care much about automating deploys to web servers, continuous integration and so on. So everything was done manually and some kind of problem was always expected (at least, I expected).
For example: sometimes a minor change was required. So the usual solution was to edit some configration file on production, since a common practice was to externalize to config files everything that could possibly change someday. The problem was that, in the next release, that change could be overriden, because it had not been reflected on the versioned project files. And I’m talking about Java web applications. A deploy, in this case, should be no big deal; just a matter of copying a file to the server. But, in practice, it was a real nightmare.
In your analogy, did the passengers demand their money back, and if so, did they get it? Or, did they demand compensation for their lost luggage, and if so, was that compensation enough to hurt the airline’s bottom line?
As the same thing happened week after week, did the passengers wise up and start giving their money to another airline? Or did most of the airlines flying to their destinations provide similar service, so that there was no better alternative?
Sometimes I think part of the problem is that in the software industry, is that there isn’t enough difference between the money a company can make from a “disaster saved by heroes” project versus a smoothly run project. Software purchasers seem to be a lot more tolerant of products that don’t live up to what they were promised than airline ticket purchasers.
And in the absence of management being able to see the connection between the amount of money the two types of projects make, it can just end up that “the squeaky wheel gets the grease.”
Also, it reminds me of these excellent slides, “Why Are My Pants on Fire?” by Elisabeth Hendrickson at http://testobsessed.com/wordpress/wp-content/uploads/2007/01/wampof.pdf
Wow – so something similar really happened? I guess considering them both heroes and villains the first time something happens makes sense – people make mistakes. The point I was trying to get across is that management should be worried when these mistakes happen over and over again – and consider them mistakes and not acts of heroism.
Here’s a real example similar to your (presumably) hypothetical example. The pilots didn’t ditch the luggage, but they landed in dramatic fashion on a disused airfield. http://www.damninteresting.com/the-gimli-glider
Interestingly, the pilots were considered to be both heroes and villains – they were punished for allowing the situation where the plane flew without adequate fuel, but rewarded for their airmanship in landing it after the fuel ran out.