Risk management for the Agile world

No notes for slide

If you’re successful with agile then you’ll get to work on bigger projects (that aren’t just software) and be asked to review business cases (that do more than create software). And those projects have risks that Agile practices can’t help with. Those risks are presented in “risk registers”. But risk registers are as helpful to managing risk as waterfall-style Gantt charts are to predicting delivery dates. This workshop is to provide just the first stepping stone to more effective ways of dealing with those project issues, and provide some pointers to where to go next.

You’ve broken out of the tech team and now people want to use your skills in bigger projects. This is what you’ll come across…

And they’ll fall like dominos

I’ve found that actions typically fall into one of three categories, none of which are very useful.

So the risk register said we were worried about this, but we were really careful about selecting the supplier, so it’s okay now. So why is it on the risk register? Or is there something you’re still worried about – in which case a past action isn’t going to help us.

From a business case I was asked to review… This is now your problem. You’ve been handed the risk register. There are real potential problems there. But the actions aren’t helpful. How can we deal with these for real?

I’ve not asked for ideas for actions, because I’m not convinced we’ll come up with much that’s useful. Instead, I’m going to look at some more practical ways of working with those so-called “risks”.

As a running example, I’m going to use some risks I’ve heard of recently in different companies. (1) Our boss says he wants the product “punchy” but won’t elaborate. We’re afraid we’ll deliver the product after six months and he’ll hate it. We can’t even write this risk down because it looks like we’re dysfunctional. (2) Our competitor launches in Germany before us – but we’ve got revenue riding on the fact that we launch first. I used to be flummoxed by these kind of things. But now I’m more confident, because I look at them differently.

Things can be good as well as bad. What is the flip side?

It’s not just “bad thing happens or it doesn’t”. It’s not black and white. There are shades of grey. And of course that’s true for good things as well as bad things.

There’s a world of difference between being beaten by our competitor by one year, three months, or 24 hours.

Zoom out. Look at the bigger picture.

For the second one, there’s much more to a successful product that being first to launch.

Here’s how I sum up those three things on one slide.

Now I want us to use those techniques to tackle the so-called “risks” we’ve written down. But as a warm-up, let’s first do some together. These are all examples I’ve found elsewhere.

This example is something being taught to engineering students, explaining risk registers to them.

Is there a positive? Client may pay fees earlier than expected. They may pay for some things in advance.

Is it variable? They pay variable days in advance, or variable days late.

What if we zoom out? Perhaps this really about incentives for the client to pay. Perhaps we can structure things so there is an incentive for the client to pay early, or pay ahead.

This is from an EBA report researching virtual currencies, and exploring possibilities for regulating things like Bitcoin. This is from their risk register.

Is there a positive? The regulatory approach is so good it can be applied back to FCs.

Is it variable? Yes, it may be successful or unsuccessful (better or worse) for different participants and players, in different circumstances.

What if we zoom out? Perhaps this is really about… our relationship with the VC world/community. Perhaps it points to our inability to experiment with or investigate regulatory options in a safe and informative environment. Maybe that’s the real problem we should be addressing.

This is from a leaked risk register in which civil servants set out potential problems for the parliamentary Bill for Andrew Lansley’s 2012 NHS re-org. Let’s apply our techniques…

Is there a positive? Yes. We may have more clarity than the Bill needs and might use that to advance changes sooner.

Is it variable? Yes, there are degrees of incompleteness.
What if we zoom out? Perhaps the Bill is tied too closely to the detailed design. Perhaps we should architect the Bill so that it aligns to the principles of the re-org, not the details.

Now it would be great if I could give you all the answers, but I’m afraid I can’t. I did say this was only a starter. However, I can give you some ideas about where to go next, and how to deal with these practically.

A great way to handle uncertainty naturally is by changing the environment… by moving the playing field.

These are hard to implement. But it’s better to tackle the difficult-but-right problem than the easy-but-wrong one.

A risk register starts us off with point risks. But when you zoom out and look at things in a more rounded way, those point risks can start appearing as small examples of bigger themes. And then we might find big solutions. S/w dev address by agile. Product/market fit addressed by Lean Startup. They both deal with uncertainty by creating a feedback loop. If you’ve got business lines that are uncertainty then try portfolio diversification.

If you want to know more, here is where I’ve found my inspiration.

Risk management for the Agile world

niksilver

Risk management for the Agile world