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?
One way to examine the project in-flight is by looking at the risks it faces.
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.
One assertion of Risk-First is that every action you take on a project is to manage a risk.
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.
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:
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.
From the above examples, it’s clear that different tools are appropriate for managing different types of risks.
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.
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. ”
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 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?
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.