The Importance of Retrospectives

Today we learned something important, the NTSB announced the results of their investigation of the the 35W bridge collapse. Turns out it was a design flaw - some gusset plates weren’t quite up to snuff. As a result of this tragedy, bridges of similar design will undergo much needed scrutiny and we won’t see these types of designs in the future. Heck, by now engineering textbooks have probably already been updated.

Contrast this with the average failing software project. Maybe this is a bit of stretch (much like the bridge construction metaphor) especially considering that few software failures result in the loss of human life. But when was the last time anyone published a report about what went wrong with a multimillion dollar software collapse? No, we bury our mistakes (near Jimmy Hoffa) and pretend that the next time, when we do it JUST like we did it this time, it will work. It’d be too difficult to admit we did something wrong, even in the “safe” confines of our own organizations protected with lengthy NDAs.

Retrospectives are a vital part of creating better software but to be effective it requires a level of maturity that few organizations posses. Taking an honest look back at what happened, what went well and what went wrong leads to better results but only if you can discuss the project/increment/whatever openly and more importantly change how you do things. Life is full of constant adjustments, why should software projects be any different?