Risky business

I’m still on vacation but am at least online after two offline weeks in Crete. The photo is by my husband, Hakan, b t w.

For me, reading is essential to the ultimate vacation, and this is no exception. I’ve tried to stay away from software development literature, but I was not totally successful. When you’re working with something, I guess every book is somehow related to the subject. So, my head is packed with new interesting topics for this coming fall. And I’m starting off with the subject of risk. Is a risky project/task worth it?

A basic principle of agile is to try to get as much business value for the least resources. This would mean that you would pick story A of the following user stories:

Story	Cost	Business value
A	10	10
B	20	10
C	10	5

But what happens if you take risk into consideration?

Story	Cost	Business value	Risk
A	10	10	10
B	10	20	20
C	10	5	30

What would you pick? A safer story with less business value or a riskier one with higher potential?

My basic instinct tells me to pick story A, and I’ve also felt somehow that the agile principles are backing me up on this. But would happen if we always pick the less risky stuff?

In Blue Ocean Strategy, W C Kim and R Maubourgne describes the differences between a red ocean and and a blue ocean when it comes to competitive situations and businesses. The principle is described very well in the current (July 2010) Wikipedia article, so feel free to take a detour if you prefer before going back here. To summarize; the red ocean is a business where the competition is dense and you need to fight for your position. If you have found a blue ocean, you’re competitors cannot truly compete with you. Of course, most blue oceans are temporary, but the successful organizations find new blue oceans when their current ones turn red. But what has this to do with my product backlog?

The answer is the question, in some ways, but you could also call it Innovation. How can you find a blue ocean? Well, it’s probably not by deselecting all the high risk items, is it?

David Andersson also points to this in his brilliant Agile Management for Software Engineering. If you’re shy of innovation, you will never be able to implement lean and agile values in a long term successful way. Implementing The Theory Of Constraints require a successful selection of both risky and non risky items. He also points at the importance of measuring the right stuff when it comes to high risk things: if you only measure the factual outcome, people will become shy of innovation and only pick the sure wins. This is probably the best way to stay in a red ocean. (And if you have not yet gotten this book, be sure to read it.)

But what are risky projects, items, tasks? It is very important to know why they are risky? Is it a risky technology? Are we unsure of the potential income? Are there special circumstances in the current project? David Andersson points at the importance of knowing WHY something is risky, but not deselecting for example all tasks with high technological risks. I’ve for example worked with a client who only worked with old versions of tools in order to lower the risk. Yes, the risks were lower but he lost out on innovation. But I’ve also worked with clients who ran for all new technology and had to be one of the first on all new versions. This is of course not good either. Now we’re not talking about risky user stories: we’re talking about misplaced focus. We won’t find the blue oceans because of new technology, but it can help us get there.

So, when my vacation is over in about two weeks, I will look differently at risk. Is there a potential blue ocean hiding there or can I get over another constraint while handling it? But now I’m heading back to my vacation.