Some highlights from Waltzing with Bears Part 2

Part 2 describes 99% of the software industry in Australia


In "The Case against Risk Management" I particularly enjoyed these little snippets...

"Some organisations are so desperate to believe they are in complete control that if they realise the aren't they settle for the illusion of control. The most common symptom of this is ridiculous precision (a very narrow window of uncertainty) attached to estimates that subsequently turn out to be very inaccurate."

Working in Agile Land we face up to the inaccuracy of our estimations everyday. We avoid trying to make precise estimates as we know this is just an illusion. So we use story points or ideal days or gummi bears or dog sizes. We assume an estimate is well an estimate, and for most people in software this is a strange idea, a confronting idea, even a stupid idea.

The whole section on Risk management in isolation is significant - ok lots the book is significant, maybe not the Library of Congress bits, and the advertising. If you start down this road to finding risks and acknowledging uncertainty but you are working in a land of happiness where uncertainty is not acknowledged you are sunk. "The worst organisations penalise unappealing forecasts, but not unappealing results". A friend working for a rather large telco told me the story of the three program managers, the first two were fired as they said the plan was impossible, the third kept their job because they agreed to the plan. Number three gave Churchillian motivational speech to his team "The schedule is impossible but we are going to stick with it anyway".


The Indy Car analogy is excellent.

"When you challenge your subordinates to pull out the stops and bring the project home on time (even though the schedule is ludicrous ... 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."

I remember discussing one of the side effects of this behaviour 12 months ago with the director media company. He was (and is) a very savvy guy in all things online, but not really in software development. We talked about how in online news it's great to have stories that have long tails ie people keep coming to read the articles after the initial burst of interest. In software development there is a long tail too, but it's not a nice one. If we have a flurry of activity trying to complete some work to a foolishly short schedule we cut corners - either intentionally or unintentionally - the long term effect is when you come back to that code it takes longer to change, the changes are riskier, and the long tail is what looks to be a small cost but it's one that adds up every time you hit that bit of code. Add to this fun that 40-60% of code is developed after release you have created for yourself a serious problem.

How can we avoid this kind of stupidity? <agile rant goes here>