A Moral Hazard: is your team insulated from the project risks?

Monday 4 August 2008

Ever been frustrated when a workmate or a member of your team made such stupid choice that you had to go in there and fix things, distracting you from the stuff you should be doing? Perhaps they weren’t able to make the right choices because they didn’t know what they were risking.

There is a term in the Insurance business: Moral Hazard. Summed up it means people insulated from a risk behave differently that if they are exposed to it. For example a driver worries less about a well insured car than an under-insured one; or an extreme example: un-insured owners are less likely to torch their factory

I think this applies to software development teams also. The team’s behaviour and choices differ depending on the risks they are exposed to. If you want the team to make wise choices and have good behaviours they need to feel the risks. If the push is just for delivered functionality above everything else, the team may choose to work on stories when there are bugs to be fixed as they have not exposed fully to the project risk of a buggy application’s release being delayed. You or someone might be concerned about it but unless the team understands the risk they are taking with continual story development, they don’t make the wisest choice.

I feel that its important that the team isn’t isolated from the risks associated with the project and I see that as ensuring the information about the critical aspects of the project are shared with them – as a team leader it can be tempted to shield them, but that leads frustration when they make choices that make no sense to the people with all the information.

2 comments :

Unknown said...

Mmmm. I've often thought, but not articulated the thought that developers can work in a dev environment bubble forgetting that the whole point of writing code and hitting targets is that it will be used by actual real life users one day.

Tom Marsh said...

Great blog Dan. Over the last 18 months my biggest take from agile development is that the you must reduce the gap between those that want the thing and those that craft the thing. It makes the requests more sane and the products more loved.