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


Staging and Classifying

Staged and Classified Beetle Collection, (Credit: Fir0002, Wikipedia)

Our tour is complete.

But if we are good collectors, then before we finish we should Stage our specimens and do some work in classifying what we’ve seen.

Towards A “Periodic Table” Of Risks

As we said at the start, Risk-First is all about developing A Pattern Language. We can use the terms like “Feature Risk” or “Learning Curve Risk” to explain phenomena we see on software projects. If we want to De-Risk our work, we need this power of explanation so we can talk about how to go about it.

Periodic Table of Risks

The diagram above compiles all of the risks we’ve seen so far on our tour across the Risk Landscape. Just like a periodic table, there are perhaps others left to discover. Unlike a periodic table, these risks are not completely distinct: they mix like paint and blend into one another.

If you’ve been reading closely, you’ll notice that a number of themes come up again and again within the different sections. It’s time to look at the patterns within the patterns.

The Power Of Abstractions

Abstraction appears as a concept continually: in Communication Risk, Complexity Metrics, Map and Territory Risk or how it causes Boundary Risk. We’ve looked at some complicated examples of abstractions, such as network protocols, dependencies on technology or Business Processes.

Let’s now generalize what is happening with abstraction. To do this, we’ll consider the simplest example of abstraction: naming a pattern of behaviour we see in the real world, such as “Binge Watching” or “Remote Working”, or naming a category of insects as “Beetles”.

Using A Known Abstraction

Using A Known Abstraction

As shown in the above diagram, using an abstraction you already know means:

Inventing A New Abstraction

Inventing A New Abstraction

As shown in the above diagram, inventing a new abstraction means:

Learning A New Abstraction

Learning a New Abstraction

As shown in the above diagram, learning a new abstraction means:

Abstraction is everywhere and seems to be at the heart of what our brains do. But clearly, like taking any other action there is always trade-off in terms of risk.

Your Feature Risk is Someone Else’s Dependency Risk

Features And Dependencies

In the Feature Risk section, we looked at the problems of supplying something for a client to use as a dependency: you’ve got to satisfy a demand (Market Risk) and service a segment of the user community (Feature Access Risk).

However over the rest of the Dependency Risk sections we looked at this from the point of view of being a client of someone else: you want to find trustworthy, reliable dependencies that don’t give up when you least want them to.

So Feature Risk and Dependency Risk are two sides of the same coin, they capture the risks in demand and supply.

As shown in the diagram above, relationships of features/dependencies are the basis of Supply Chains and the world-wide network of goods and services that forms the modern economy. The incredible complexity of this network mean incredible Complexity Risk, too. Humans are masters at coordinating and managing our dependencies.

The Work Continues

On this journey around the Risk Landscape we’ve collected a (hopefully) good, representative sample of Risks and where to find them. But there are more out there. How many of these have you seen on your projects? What is missing? What is wrong?

Please help by reporting back what you find.

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