Using Data for Risk Management in Software Engineering

Share This Post

According to the Standish Group’s latest report, CHAOS 2020: Beyond Infinity, only 35% of software projects are completed on time and within budget. That’s a sobering statistic and a compelling reason to discuss risk management in software engineering.

Education Fail GIF by Hogeschool van Amsterdam - Find & Share on GIPHY

Software engineering projects involve a great deal of uncertainty. That uncertainty quickly turns into missed deadlines, abandoned features, broken code, and lost revenue. Software risks easily become business risks.

This post will cover risk management in software engineering, paying particular attention to how elite teams leverage LinearB to reduce uncertainty and risk.

What is Risk Management in Software Engineering?

As a software leader, it’s your job to ensure that a project is completed on time, on budget, and with a product that meets the requirements. Risks are the potential obstacles your team will encounter along the way.

Risk management is the art of reducing your risk exposure and mitigating the impact when things go awry. You can’t prevent every obstacle your project will encounter, but you can identify them before they happen. You can also form a risk management plan so that you know what to do when the risks don’t pan out well.

What are some of the problems your project might suffer from?

  • Unforeseen bugs that require immediate action
  • Outages of other services that you depend upon
  • Delays from partners or vendors
  • Loss of personnel due to illness or resignations
  • Cost overruns

Dealing with these issues as they occur isn’t risk management – it’s crisis management, and it’s why 65% of projects fail, finish late, and go over budget. Risk management is the opposite of crisis management: You turn a crisis into a planned event by identifying and eliminating risks in advance and also formulating a plan and executing it when the problem occurs.

Risk management involves these activities:

  • Identifying the different types of risks and what causes them
  • Formulating plans to deal with them if they happen
  • Establish processes to monitor projects for risks
Dealing with these issues as they occur isn't risk management. It's crisis management, and it's how 65% of projects fail, finish late, and go over budget.

Techniques for Managing Risk in Software Engineering

Managing risk is a core design principle in Agile software project management frameworks like Scrum. Let’s look at the most effective tactics you can use to manage risk.

Spikes

In Agile, a spike is a placeholder for a user story. A spike says: “We need more information about this before we can make an informed work estimate.” Team members can then investigate and gather the required information.

Spikes are an opportunity to gather the knowledge required to reduce the risk of charging ahead on a user story without understanding all the details. Spikes represent uncertainty. That’s what makes them a favorite risk management tool of project managers. Spikes explicitly call out unknowns in your development process and enable you to gather the data you need to remove the risk of that uncertainty.

Reduce Pull Request Review Time

On the Dev Interrupted podcast, Charity Majors, CTO of Honeycomb, explained the risks of a long interval between when code is written and when it is deployed:

When changes get stuck at a bottleneck, they stack up and it takes a lot more effort to get them through to deployment. Then once they are deployed, there’s a higher risk that they will cause problems because they’re now out of date and are entering production alongside lots of other changes.

These issues require action from your team, which takes time away from executing on your project plan.

From studying almost 2,000 engineering teams, LinearB learned that average pull request review time is over 4 days. And of that time, PRs spend about half (2 full days) just sitting idle.

Although long PR review times are a major problem, they thankfully have a straightforward solution: reduce the size of pull requests. Our research also found that PRs under 225 lines of code get reviewed up to 10x faster.

Nobody wants to review your huge pull request. Book a demo of WorkerB PR size alerts.
Improve your code quality and developer workflow with smaller pull requests. Book a demo of LinearB today.

Cone of Uncertainty

The Cone of Uncertainty describes how the unknowns in a software project decrease over time. When you first start a project, your estimates tend to be inaccurate. But as the project progresses, your estimates improve and your project success rises.

This chart illustrates the phenomenon.

cone of uncertainty

The vertical axis shows the variability or “fudge factor” of estimates. The horizontal axis shows time. As time progresses, the variability of your estimates shrinks until it finally converges on 1: you’ve learned enough about the project that your estimates have become highly accurate.

With LinearB, you can accelerate this process. Our Planning Accuracy metric shows you how well you’re planning across time so that you can see your efforts are working and course correct. In addition, you can compare yourself to the benchmarks we established by analyzing almost 2,000 development teams.

Planning accuracy with engineering benchmarks from LinearB

Managing Iterations

Putting monitoring processes in place so you detect risks before they turn into problems is key to risk mitigation. Agile already has a mechanism built-in to help you with that: sprints. Sprints and the way Agile structures them serve as key risk management tools.

Short sprints with tight feedback loops are intended to give developers a steady stream of feedback. This feedback tells developers how well they’re doing, so they can celebrate their successes and learn from their mistakes.

But these short iterations and tight feedback loops also help you monitor for risks. Each sprint is an opportunity to evaluate your team’s progress and adjust your timelines. If user stories are starting to slip, you can adjust your schedule. And, of course, as the project advances, you and your team should be thinking about that cone of uncertainty: Are you getting better at estimating effort? If not, there’s something you don’t know.

They’re also a chance to check in with the project stakeholders. What happens when their feedback includes requests for more or drastically different features? You’re looking at scope creep, and it may be time to take a step back and reevaluate your plans or raise the alarm.

Testing

Testing is a monitor for risk management, too. Code failing in production is one of the biggest risks you’re trying to avoid, so testing it before you deploy it is one of the most essential (and obvious) things you can do.

But regression testing each iteration, whether it’s destined to be deployed to production or not, generates key metrics, too. Code should improve with each iteration, not get worse and fail regressions.

3 High-Leverage Ways LinearB Can Help

LinearB helps you manage risk by combining and analyzing the data generated by your developers in code commits and Jira updates. We use this data to create metrics and charts as well as helpful automations via our WorkerB automation bot.

Let’s look at 3 high-leverage tactics to manage risk available with LinearB.

Eliminating Shadow Work

Shadow work is work that isn’t connected to a Jira artifact. It means that your developers are working on issues that aren’t related to your current project. Maybe the work is unplanned, or maybe your Jira tickets haven’t captured all of the work required to get it done.

Staying Ahead of High-Risk Pull Requests

Although by definition bugs are unforeseen, you can reduce the probability that buggy code is merged into production and head off potential problems. LinearB has found that high-risk diffs share 2 characteristics:

  1. They are large, which makes them more complex and harder to review and test.
  2. They contain a lot of reworked or refactored code, indicating that they are impacting existing functionality.

Using this definition, we can leverage our WorkerB automation bot to send out automated notifications, alerting you and the team when a high-risk diff has been created. This enables you to act before the code gets pushed into production and creates problems.

Laugh in the face of danger with high risk work detection. Schedule a demo of WorkerB.
Want to eliminate risky behavior around your PRs? Book a demo of LinearB today.

Preventing Burnout

How’s your team doing? LinearB can help you ensure they’re thriving. Burnout indicators tell you if they’re suffering from cognitive overload because of too much work in progress, sending you an alert when a developer may be working too hard.

team health

Data for Risk Management in Software

Risk is inherent to any software development project. But with the right tools and techniques, you can greatly reduce it and mitigate the negative impacts if the risks transpire.

LinearB gives you the data you need to illuminate and weed out uncertainties and risks in your projects. With our WorkerB automation bot and Team Goals, you can then drive sustained improvements so that your team can consistently deliver on your promises and ship performant, reliant software within budget and on time.

LinearB is free for teams 8 people or smaller. Give it a try today or reach out to set up a demo to learn about all the ways LinearB can help your team ship high quality code faster.

Improve your engineering organization at every level with LinearB
Want to improve your engineering processes at every level? Get started with LinearB today!

More To Explore

Never miss a post

Join our community of data-driven dev leaders

Each week we share stories and advice from engineering and product leaders striving to be better for their teams

Join our community of data-driven dev leaders