When you challenge your subordinates to pull out the stops and bring your project home on time (even though the schedule is ludicrous), you need to understand that you are staffing your key positions with NASCAR racers. They will take every chance, ignoring every imaginable downside, in order to preserve – at least for the longest time possible – any thin, little chance of winning.

The Gist

If you aren’t on board with software risk management by now, your company may be living 20+ years in the past. DeMarco and Lister discuss the importance of risk management and methods to convince others in your company that risk management is important in Waltzing with Bears.

My Opinion

This is an important book. Written during a pivotal moment in the IT industry prior to the Dot-Com Bubble, it is incredible to think that any software product can be built while ignoring any risks. I’m grateful to be a member of an organization that not only thinks about risk, but puts an emphasis on risks, especially before project work begins. I’ve yet to hear many companies who do a good job of thinking about risk in the middle of a project (pre-implosion), but DeMarco and Lister are desparate to convince me to think about risks all the time. Fortunately, I’m not a manager.

The authors hit hard on the fact that some projects fail: from their research, one out of seven projects will not see the light of the day. This is a huge figure, but even I’ve experienced a discontinued project in my short career as a software engineer. The authors don’t tell us how to mourn the death of a project, but simply warn us that it’s always a possibility.

We can adapt to most risks - this dropdown widget has poor performance so we’ll swap it for a simpler widget, UX doesn’t like the way this looks so we’ll revisit it, the vendor stopped responding to emails so we’ll roll our own - but there are other risks which are much more difficult to recover from. Have you added in the risk of your lead developer leaving the company? What happens if your office’s landlord suddenly ends your lease? How can you deal with a client project which takes up 30% of your company coming to an end? Although the authors don’t tell us how to deal with these problems, they encourage us to always keep them in mind when planning.

It seems that the Agile Invasion has come to save us from some of these problems. We plan our work iteratively so we can embrace change (as long as it happens outside fo sprint boundaries). We estimate stories or tasks to enhance our wild guesses about how long our work will take. Our lead developers pair with young padawans to spread knowledge throughout the team. Although Agile methodologies are more ubiquitous these days, it’s clear that this book was written before the adoption of these ideas.

Waltzing is all about managing risk: emphasis on the managing. As a software developer, my role seems to be a bit more fuzzy. The authors encourage the development team to express their concerns, but there isn’t much else to do afterwards. The rest seems to lie in the hands of managers conveying these concerns to the stakeholders and deciding which risks are worth accounting for. The authors also mention using tools to perform Monte Carlo simulations to add risk into project estimations - a tactic useful for managers pre-product-kickoff, but not so useful once you’re in the trenches trying to build a product.

Who Would Like This

Mostly managers or those who want to know things managers need to consider. As an engineer, there seems to be little I can do except to express concerns. I still enjoyed reading this book to get a manager’s perspecitve on software development. These are the same guys who co-authored Peopleware, which is a must-read for anyone in the software world, so it’s certainly worth at least reading the back cover of Waltzing.