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:

• A story about improving the user login screen can be seen as reducing the risk of users not signing up.
• A task about improving the health indicators could be seen as mitigating the risk of the application failing and no-one reacting to it.
• Even a task as basic as implementing a new function in the application is mitigating the risk that users are dissatisfied and go elsewhere.

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:

• In manufacturing, tolerances allow for calculating the likelihood of defects in production.
• In finance, projects and teams are structured around monitoring risks like credit risk, market risk and liquidity risk.
• Insurance is founded on identifying particular risks and providing financial safety-nets for when they occur, such as death, injury, accident and so on.

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:

• Talk about the types of risks we face on our projects, using an appropriate language.
• Anticipate Hidden Risks that we hadn’t considered before.
• Weigh the risks against each other, and decide which order to tackle them.

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:

• If we do a Code Review, we are partly trying to minimise the risks of bugs slipping through into production, and also manage the Key Person Risk of knowledge not being widely-enough shared.
• If we write Unit Tests, we’re addressing the risk of bugs going to production, but we’re also mitigating against the risk of regression, and future changes breaking our existing functionality.
• If we enter into a contract with a supplier, we are mitigating the risk of the supplier vanishing and leaving us exposed. With the contract in place, we have legal recourse against this risk.

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:

• Agile methodologies prioritise the risk that requirements capture is complicated, error-prone and that requirements change easily.
• Waterfall takes the view that development effort is an expensive risk, and that we should build plans up-front to avoid re-work.
• Lean takes the view that risk lies in incomplete work and wasted work, and aims to minimise that.

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:

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 Taxonomy 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:

• If we are introducing a Sign-Off in our process, we have to balance the risks it mitigates (coordination of effort, quality control, information sharing) with the risks it introduces (delays and process bottlenecks).
• If we build in Redundancy, this mitigates the risk of a single point of failure, but introduces risks around synchronizing data and communication between the systems.
• If we introduce Process, this may make it easier to coordinate as a team and measure performance but may lead to bureaucracy, focusing on the wrong goals or over-rigid interfaces to those processes.

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.