Fork me on GitHub
Risk First Logo

Home of Risk-First Software Development



Start Here


Home
Contributing
Quick Summary
A Simple Scenario
The Risk Landscape

Discuss


Please star this project in GitHub to be invited to join the Risk First Organisation.

Blog


Consuming Hacker News 14 May 2019
Twitter Cards 22 March 2019
Next - Scrum? 7 March 2019
Available On Amazon 25 February 2019
New Proof 10 February 2019

Publications



Click Here For Details


The Risk Landscape

In the previous section, we saw how Lean Software Development owed its existence to production-line manufacturing techniques developed at Toyota. And we saw that the Waterfall approach originally came from engineering. If Risk-First is anything, it’s about applying the techniques of Risk Management to the discipline of Software Development (there’s nothing new under the sun, after all).

One key activity of Risk Management we haven’t discussed yet is categorizing risks. Thus, Part 2 of Risk-First is all about developing categories of risks for use in Software Development.

The Risk Landscape Again

In Meeting Reality, we looked at the concept of the Risk Landscape, and how a software project tries to navigate across this landscape, testing the way as it goes, and trying to get to a position of more favourable risk.

It’s tempting to think of our Risk Landscape as being like a Fitness Landscape. That is, you have a “cost function” which is your height above the landscape, and you try and optimise by moving downhill in a Gradient Descent fashion.

However, there’s a problem with this: as we said in Evaluating Risk, we don’t have a cost function. We can only guess at what risks there are. We have to go on our experience. For this reason, I prefer to think of the Risk Landscape as a terrain which contains fauna and obstacles (or, specifically Boundaries).

Just as I can tell you that the landscape outside your window will probably will have some trees, fields and buildings, and that the buildings are likely to be joined together by roads, we can make generalisations about risks too.

Why Should We Categorise The Risks?

A lot of knowledge and understanding of the world starts by naming and categorising things.

If we were studying insects, this might be a guide giving you a description and a picture of each insect, telling you where to find it and how it lives. That doesn’t mean that this is all there is to know. Just as a scientist could spend an entire lifetime studying a particular species of bee, each of the risks we’ll look at really has a whole sub-discipline of Computer Science attached to it, which we can’t possibly hope to cover in any great depth.

As software developers, we can’t hope to know the specifics of the whole discipline of Complexity Theory, or Concurrency Theory. But, we’re still required to operate in a world where these things exist. So, we may as well get used to them and ensure that we respect their primacy. We are operating in their world, so we need to know the rules.

Once we can spot and name different types of risk we can then think about their characteristics and how to manage or avoid them. Over the following pages, we’re going to take a tour of various different categories of risks, exploring their characteristics and sometimes suggesting actions to take to deal with them. But foremost, this is a “spotters’ guide” to software risks and where to find them.

Our Tour Itinerary

Below is a table outlining the different risks we’ll see. There is an order to this: the later risks are written assuming a familiarity with the earlier ones. Hopefully, you’ll stay to the end and see everything, but you’re free to choose your own tour if you want to.

Risk Description
Feature Risk When you haven’t built features the market needs, or the features you have built contain bugs, or the market changes underneath you.
Communication Risk Risks associated with getting messages heard and understood.
Complexity Risk Your software is so complex it makes it hard to change, understand, or run.
Dependency Risk Risks of depending on other people, products, software, functions, etc. This is a general look at dependencies, before diving into specifics like…
Scarcity Risk Risks associated with having limited time, money or some other resource.
Deadline Risk The risk of having a date to hit.
Software Dependency Risk The risk of depending on a software library, service or function.
Process Risk When you depend on a business process, or human process to give you something you need.
Boundary Risk Risks due to making decisions that limit your choices later on. Sometimes, you go the wrong way on the Risk Landscape and it’s hard to get back to where you want to be.
Agency Risk Risks that staff have their own Goals, which might not align with those of the project or team.
Coordination Risk Risks due to the fact that systems contain multiple agents, which need to work together.
Map And Territory Risk Risks due to the fact that people don’t see the world as it really is. (After all, they’re working off different, imperfect Internal Models.)
Operational Risk Software is embedded in a system containing people, buildings, machines and other services. Operational risk considers this wider picture of risk associated with running a software service or business in the real world.

After the last stop on the tour, in Staging and Classifying we’ll have a recap about what we’ve seen and make some guesses about how things fit together.

Causation & Correlation

Although we’re going to try and categorise the kinds of things we see on this Risk Landscape, this isn’t going to be perfect, because:

Risk is messy. It’s not always easy to tease apart the different components of risk and look at them individually. Let’s look at a high-profile recent example to see why.

The Financial Crisis

In the Financial Services industry, whole departments exist to calculate different risks like:

In the financial crisis of 2007, these models of risk didn’t turn out to be much use. Although there are lots of conflicting explanations of what happened, one way to look at it is this:

All the Risks were correlated. That is, they were affected by the same underlying events, or each other.

Causation shown on a Risk-First Diagram.  More complexity is likely to lead to more Operational Risk

It’s like this with software risks, too, sadly. For example, Operational Risk is going to be heavily correlated with Complexity Risk: the more complex your operation, the more risky it will be. In the Risk-First diagrams, we will sometimes show correlation or causation with an arrow, like in the diagram above.

We’re all Naturalists Now

Just as naturalists are able to head out and find new species of insects and plants, we should expect to do the same. Risk-First is by no means a complete picture - it’s barely a sketch.

It’s a big, crazy, evolving world of software. Help to fill in the details. Report back what you find.

So, let’s get started with Feature Risk.

Found this interesting? Please add your star on GitHub to be invited to join the Risk-First GitHub group.