Risk-First Diagrams Explained
Throughout A Simple Scenario we used diagrams to explain the risks we faced and the choices we were making. These are called "Risk-First Diagrams". Here, we're going to look at what is going on in these diagrams so that when we come to apply them to software development, they're not totally confusing.
Here's another. In the diagram above we are dealing with the risk of not having enough food at the party by considering buying lots of snacks.
What’s going on in these diagrams? How should we interpret them? Let’s work left-to-right.
On The Left
On the left in the first example we can see our goal, of having a successful party. This is the goal we want to reach, it's within our grasp to achieve this, if we only take the right actions.
Equally, we could have a risk that we wish to avoid, such as having nothing to eat at the party. To achieve that, we also need to take the right actions.
Cause and Effect
There are all kinds of risks we face in life and we attach different value or criticality to them. Most people will want to take action against the worst risks they face in their lives and maybe put up with some of the lesser ones. Equally, we should also try and achieve our most critical goals and let the lesser ones slide (at least, from a rational standpoint).
In The Middle
In the middle of a Risk-First diagram we see the actions you could take. In the diagram above, echoing the examples, they are "Hosting a Party" and "Buying Snacks". One is moving us towards the goal of "A Successful Party", the other, moving us away from the risk of "Not Enough Food".
On The Right
Nothing comes for free. On the right, you can see the consequences of the actions you've taken: Attendant Risks are the new risks you now have as a result of taking the action.
Hosting a dinner party opens you up to attendant risks like "Not Enough to Eat". As a result of that risk, we consider buying lots of snacks. As a result of that risk, we start to consider whether our guests will be impressed with that.
It's worth pointing out that sometimes the cure is worse than the disease.
By Taking Action you might end up in a worse predicament than you started. For example, cutting your legs off would definitely cure your in-growing toenail. We have to use our judgement to decide on the right course of action!
So Risk-First diagrams represent a balance of risk: whether or not you choose to take the action will depend on your evaluation of this balance. Are the things on the left worse or better than the things on the right?
We are tranforming an input condition (on the left) into an output condition (on the right) by way of a function (the action we take, in the middle).
Containers For Internal Models
The risks on the left and right are contained in rounded-boxes. That's because risks live in our Internal Models - they're not real-world things you can reach out and touch. They're contained in things like brains, spreadsheets, reports and programs.
Example: Blaming Others
In the above diagram, you can see how Jim is worried about his job security, probably because he's made a mistake at work. Therefore, in his Internal Model he has Funding Risks, i.e. he's worried about money.
What does he do? His Action is to blame Bob. If all goes according to plan, Jim has dealt with his risk and now Bob has the problems instead.
The diagram above shows two other marks we use quite commonly: we put a "strike" through a risk to show that it's been dealt with in some way and the "cloud" icon denotes Hidden Risks- those unknown unknowns that we couldn't have predicted in advance.
Risk-First is about understanding risk in software development, so next let's examine the scenario of a new software project. Instead of a single person organising a dinner party, we are likely to have a team, and our Internal Model will not just exist in our heads, but in the code we write.
On to Development Process...