Q&A on the Book Risk-First Software Development

The book Risk-First Software Development by Rob Moffat views all of the activities on a software project through the lens of managing risk. It introduces a pattern language to classify different risks, provides suggestions for balancing risks, and explores how software methodologies view risks.

InfoQ readers can download a sample of Risk-First Software Development.

InfoQ interviewed Moffat about how risks drive everything we do, the relationship between software methodologies and risks, dealing with feature risks in backlog grooming, mitigating risks that can occur when we use open-source libraries or software as a service functionality, dealing with heroes in teams, the challenges that come with operating software systems in the real world and how to deal with operational risks, and future books about the risk landscape.

InfoQ: Why did you write this book?

Rob Moffat: This started out as an observation in my log book:  my team spent a lot of time planning meetings trying to decide what build, and how to build it.   We seemed to be trying to avoid taking risky paths that would lead us into dependency hell, leave us with technical debt or lead us to build the wrong thing for our users. Although on one level we were working on a Scrum team, it felt like actually, what we were mainly doing was trying to avoid unnecessary risk.   

Understanding that we were avoiding risk in those planning meetings, I was able to make the realisation that actually, all the work we do as developers is about risk. For example, if you’re working on making the sign-up screens for your web-app less confusing, what you’re actually doing is trying to reduce the risk that potential customers walk away.   Or, if you’re working on improving the health indicators of the application, you’re actually trying to reduce the risk of customers facing downtime, and the reputational risk and potential loss of revenue that results from it.   

It felt like this was a concept beyond merely “Agile” that hadn’t been properly explored, so I started writing a few blog articles, mainly for my own benefit, to try and figure out this concept.  This really snowballed into a github wiki (all the content for the book is also published on riskfirst.org).

Eventually, I decided it would be fun to publish it in book-form too.   

InfoQ: For whom is this book intended?

Moffat: This book is for people working on software projects.  If you have an interest in what makes software development work (or fail), then this might be something for you.  Although by now we are all familiar with techniques such as Agile or DevOps, it feels like Risk-First is trying to go beyond that and explain at a lower level why these methods and practices work and their limits.  

InfoQ: You stated in the book that risk drives everything we do. Can you elaborate?

Moffat: Sure, let’s discuss some examples.  A development story about improving the user login screen can be seen as actually being about reducing the risk of potential clients not signing up.  Or, when we do some work to implement health indicators, this is about minimizing the risk of the application failing and no one reacting to it. 

If my software doesn’t do something that my competitor’s software does, then you could call that a Feature Risk; there’s a risk that I lose market share because I don’t provide the feature.  Alternatively, if my software has lots of third-party dependencies, then that might lead to a high level of Dependency Risk; those third-party dependencies may contain bugs, security flaws or change with time in ways that I don’t want them to. 

There may be a trade-off here too; if I build my missing feature, I might decrease the amount of Feature Risk, but I might end up increasing the amount of Dependency Risk as a result.  

InfoQ: How do you see the relationship between software methodologies and risks?

Moffat: A software methodology is really a set of tools to help you build the right product.  It might help you manage your time (through things like Sprints) or your team (with roles such as product owner or coach) or your work (through maybe a Kanban board).

The Risk-First idea is that all the tools we have (whether methodologies, processes or software tools) are there to help us manage certain kinds of risks.   The interesting thing that is explored in the book is that different methodologies have different ideas about which risks are important to manage.

For example, Waterfall is a methodology inherited from the construction industry. So it manages the risks that you would care about in a construction project. For example, up-front blueprints minimise the risk of rework, and the risk of costs spiralling during the physical phase of the project.  This is an important risk to manage in construction because pouring concrete is significantly easier than digging it out again after it sets.  

The XP Methodology has a different idea about what the important risks are in a software project (for example, things like Key Person Risk).  As a result, its practices are very different from those on a Waterfall project (for example, Pair Programming).

So the choice of methodology and tools we use to control our project is contingent on the risks the project faces; you need to fit the methodology and the practices to the profile of the risks on the project.

InfoQ: What are feature risks and how can we deal with them in backlog grooming?

Moffat:  Feature Risks are a family of risks associated with the features of the software you’re building for your clients.   One mentioned already is the risk of missing features, and customers being unsatisfied with that.  But we also need to consider features being broken, hard-to-find, or not working the way users expect them to; and Feature Fit Risk, which is when clients have an expectation about what the product should do, but it actually delivers something else.

These are useful concepts to have on board, because when you’re trying to organise the backlog, what you’re really trying to do is de-risk the project; the items at the top of the backlog should be the items that are the riskiest. At the bottom of the backlog we have items that don’t present much feature risk, and we might remove them; they’re just causing unnecessary cognitive load and are a waste of time to have on the list (which represents a kind of Schedule Risk to us).

InfoQ: What risks can occur when we use open-source libraries or software as a service functionality? How can we mitigate such risks?

Moffat: We’re talking here about different types of dependencies, and you inevitably pick up Dependency Risk when you make use of a third party’s software or service.  Generally, once you choose a dependency (whether it’s open-source, commercial, SaaS or whatever) you’re going to end up with some kind of commitment, and it’s usually harder to back out of this commitment than it is to get into it.  

There are a lot of indicators you can look at when choosing dependencies, such as popularity of the product, size of the organisation, the amount of documentation and so on, but what you are really trying to gauge is your level of Reliability Risk, and whether or not the dependency supplies the features you need (Feature Fit Risk again).  

InfoQ: You mentioned in the book that having one or more heroes on a team can pose risks. What's your suggestions for dealing with heroes?

Moffat: Whenever you have a team of people involved on a project, they will inevitably bring to the project not just their own talents and skills, but their own goals and agendas too. Risk-First considers this conflict between the team goal and one of its members to be an example of “Agency Risk”, and this includes behaviours like CV-building and promoting “Pet Projects”. 

Heroism is usually more benign though.  While often heroes are pulling for the team, sometimes they are trying to make themselves indispensable (creating Key Person Risk) or trying to assert their own vision on the project. In these cases, the goals of the project don’t coincide with the goals of the hero.   

As a team leader, there are a few things you can do about this. You can choose to do nothing, if you believe that the risks created by having a hero are a small price to pay for the amount of other project risks they are mitigating. Alternatively, and probably the most humane response, is to try and examine why it is that the goals of the hero don’t align with the project, and see what can be done to align them better. Perhaps the hero is trying to make themselves indispensable because they feel their job is at risk?  As a team leader, you can probably do something about that.

InfoQ: What challenges come with operating software systems in the real world?

Moffat: Often, the risks we face in the smallare the same as the ones in the large.  An unreliable software module can be a source of Dependency Risk, but so can an unreliable supplier, or an unreliable employee.  Similarly, I can construct software that has too much Complexity Risk and needs simplifying, but sometimes, whole organisations are too complex and need simplifying.   

What you might find at different scales is that the balance of the risks you face might change.  When you are starting out building some new software, it might be that you are mostly concerned with Feature Risk - just getting useful software in front of potential clients.  But when you are operating a software system the size of Facebook (say), the concerns might be more about Reputational Risk.  Actually, Facebook is a good example of this, because when they started out their motto was, “Move fast and break things”, but they changed away from that in 2014 to something more about reliability: “Move fast with stable infrastructure”.

So, I guess the answer is very much “it depends” - but by attempting to name and classify different types of risk, we can at least talk about what is the most important thing to address, and we can see how the different risks “rhyme” at different scales and in different contexts. 

InfoQ: How can we prepare ourselves to deal with operational risks?

Moffat: One concept I find useful is the idea of the “Internal Model”. That is, the things that a person, a team or a whole operation thinks they know about the world.  This Internal Model therefore contains a view on the known risks, and how serious they are. But, there are Hidden Risks that aren’t in the Internal Model, and these are often the ones that cause the most problems.

There is a lot of good pre-existing literature on operations management which I don’t want to go over, but generally speaking, you want to be testing and improving your Internal Model as often as possible.  Risk-First calls this “Meeting Reality” and it happens every time you try and do something, because you’ll find out at at that point whether your Internal Model was good enough or not to do it.  

If you’re running an operation, you’ll want to try and build in feedback loops, to ensure that you’re “meeting reality” as frequently and as thoroughly as possible. If you think about it, whether you’re doing automated builds, beta testing or running a disaster-recovery scenario, in every case you are testing to make sure your Internal Model matches up with reality.

InfoQ: In the first book of the series, you covered the Risk Landscape. What can we expect to see in future books?

Moffat: The Risk Landscape is the idea that whenever we do something to deal with one risk, what’s actually happening is that we’re going to pick up other risks as a result. For example, hiring new developers into a team might mean you can clear more Feature Risks (by building features the customers need), but it also means you’re going to pick up Coordination and Agency Risk, because of your bigger team. So, you’re moving about on a Risk Landscape, hoping to find a nice position where the risks are better for you.

This first volume of Risk-First Software Development was all about that landscape, and the types of risks you’ll find on it.  I am planning a second volume, which again will all be available to read on riskfirst.org. This will focus more on the tools and techniques you can use to navigate the Risk Landscape.  

For example, if I have a distributed team, I might face a lot of Coordination Risk, where work is duplicated, or people step on each other’s toes.  What are the techniques I can use to address that?  I could introduce a chat tool like Slack, but it might end up wasting developer time and causing more Schedule Risk.  Or I could try to subdivide the system so that different developers have different responsibilities, but this might mean the software doesn’t get correctly factored, and is a source of increased Complexity Risk or Key Person Risk. 

Volume 2 will also look more closely at methodologies as collections of practices which manage risks.  It’s going to take apart the practices of Scrum, XP, DevOps, Lean, SAFe and so on, and try to examine exactly which risks they address and how.

But, it’s early days for that yet.  If you want to stay in the loop for how that develops, then please star the project on GitHub to be invited to join the Risk-First team.  I send out a message with the updates every couple of weeks to say how this is progressing, and there are some interesting pieces software in the works for interacting with and visualizing Risk-First content and diagrams coming soon.

About the Book Author

Rob Moffat is a software developer who should know better when to give up.  He has been learning to build software since he was in short trousers, and honestly can’t see any future scenario where he is both alive and not doing that.  He lives in the UK near London, and has set up riskfirst.org, an effort to uncover the patterns underlying the way software projects work.