Fork me on GitHub
Risk First Logo

Home of Risk-First Software Development

Start Here

Quick Summary
A Simple Scenario
The Risk Landscape


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


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


Click Here For Details

Quick Summary

1. There are Lots of Ways to Run Software Projects

There are lots of ways to look at a project in-flight. For example, metrics such as “number of open tickets”, “story points”, “code coverage” or “release cadence” give us a numerical feel for how things are going and what needs to happen next. We also judge the health of projects by the practices used on them, such as Continuous Integration, Unit Testing or Pair Programming.

Software methodologies, then, are collections of tools and practices: “Agile”, “Waterfall”, “Lean” or “Phased Delivery” all prescribe different approaches to running a project, and are opinionated about the way they think projects should be done and the tools that should be used.

None of these is necessarily more “right” than another: they are suitable on different projects at different times.

A key question then is: how do we select the right tools for the job?

2. We Can Look at Projects in Terms of Risks

One way to examine the project in-flight is by looking at the risks it faces.

Commonly, tools such as RAID logs and RAG status reporting are used. These techniques should be familiar to project managers and developers everywhere.

However, the Risk-First view is that we can go much further: that each item of work being done on the project is to manage a particular risk. Risk isn’t something that just appears in a report, it actually drives everything we do.

For example:

One assertion of Risk-First is that every action you take on a project is to manage a risk.

3. We Can Break Down Risks on a Project Methodically

Although risk is usually complicated and messy, other industries have found value in breaking down the types of risks that affect them and addressing them individually.

For example:

Software risks are difficult to quantify, and mostly, the effort involved in doing so exactly would outweigh the benefit. Nevertheless, there is value in spending time building classifications of risk for software. That’s what Risk-First does: it describes a set of risk patterns we see every day on software projects.

With this in place, we can:

4. We Can Analyse Tools and Techniques in Terms of how they Manage Risk

If we accept the assertion that all the actions we take on a project are about mitigating risks, then it stands to reason that the tools and techniques available to us on a project are there for mitigating different types of risks.

For example:

From the above examples, it’s clear that different tools are appropriate for managing different types of risks.

5. Different Methodologies are for Different Risk Profiles

In the same way that our tools and techniques are appropriate for dealing with different risks, the same is true of the methodologies we use on our projects. We can use a Risk-First approach to examine the different methodologies, and see which risks they address.

For example:

Although many developers have a methodology-of-choice, the argument here is that there are trade-offs with all of these choices.

Methodologies are like bicycles, rather than religions. Rather than simply believing, we can take them apart and see how they work.

6. We can Drive Development With a Risk-First Perspective

We have described a model of risk within software projects, looking something like this:

Methodologies, Risks, Practices

How do we take this further?

One idea explored is the Risk Landscape: although the software team can’t remove risk from their project, they can take actions that move them to a place in the Risk Landscape where the risks on the project are more favourable than where they started.

From there, we examine basic risk archetypes you will encounter on the software project, to build up a vocabulary of Software Risk, and look at which specific tools you can use to mitigate each kind of risk.

Then, we look at software practices, and how they manage various risks. Beyond this we examine the question: how can a Risk-First approach inform the use of this practice?

For example:

Risk-First aims to provide a framework in which we can analyse these actions and weigh up accepting versus mitigating risks.

Still interested? Then dive into reading the introduction.

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