Space Shuttle Columbia

Space Shuttle Challenger in one of the most famous (and chilling) space photos of all time.

As I read this week’s Telegraph obituary of a great American rocket scientist, I was moved to thinking about how we deal with the whistleblowers and truth-tellers in an agile world.

How can we strike a balance between encouraging transparency and realism, while managing the impact on the morale of tight-knit teams from Negative Nigels and Whining Winifreds?

I’ll be the first to say that the command and control culture of committed waterfallers (like NASA) is a fast track to secrets being kept, and problems being swept under the carpet. When “failure is not an option” on a project racing toward a fixed launch date, with scope being secretly trimmed off Gantt charts to ensure compliance with public commitments and budgets, and all-nighters pulled by tech heroes, we are just hiding failure.

Is agile any different? If it is effective, yes. But agile zombies, with their card carrying undead marching into retrospectives and standups ritually chanting out their obligations so they can get back to their desks as quickly as possible, is probably just as bad as waterfall.

This tragic tale of an ignored voice is a stern reminder of the consequences of avoiding talking about engineering issues.

When I arrived at Lonely Planet in 2007, and proceeded to shut down a failed waterfall-delivered website program, the HR team had already initiated a training program called Effective Conversations. It seemed uncomfortably basic and quaint in intent – teaching people to get good information across quickly and confidently when in meetings, in casual conversations, one on ones, or in the lunch queue.

A month later, I knew it was gold – I had yet to find a person who did not say “I knew that would happen”. People had just not managed to get the complexity and interdependence of the hairball of product and architecture problems across to Steering Committees and executives. And after a few public scoldings for being naysayers, they learned to shut up and soldier on.

Edward Tufte tackled this same issue of communicating complexity for NASA after the second major shuttle program disaster – Columbia in 2003. This $7 report from his website is one of the best training guides for agilists to invest in around effective written communication.

The constraints put upon Boeing and NASA engineers to explain the complexity of the situation where chunks of insulation had broken off the booster rockets and damaged the heat protective tiles on the leading edge of the wing, using Powerpoint slides with bullets points and a constrained number of words per line, was too great. The wrong decision was made to not space walk and inspect the damage.

I wonder if that was a ‘didn’t work’ or just a ‘puzzles us’ in a retro sense? Either way it signaled the beginning of the end for the second great chapter of the USA’s space exploration efforts. If you are facing an ever increasing complexity in your product and IT architecture, our advice is to put as much investment into improving everyone’s communication skills as you are any engineering effort.

Buy your copy of Edward Tufte’s handbook from his website here.