A Little Risk Goes A Long Way

Risk is a big topic, but generally for beginning agile teams (or any team) it can be calculated in a minimalist way as dependencies. To me, dependencies represent a binary probability. Either they are resolved or not.

When paired with value, risk becomes super important to look at because it can tell you how much of that value is in danger. Specifically, we can use it to make informed decisions about investment.

Regarding value

For now, I will take a look at value through the lens of Net Present Value (NPV) because the program I am currently coaching is already using it. I am not advocating for NPV, just meeting the program where they currently stand. Boiling it way down… Net Present Value is used in capital budgeting to represent the profitability of an investment over time. In agile, this might be an investment in an epic or a feature or a capability, etc. You also might use story points as a super simple starting place until you figure out what value means in your organization. Net Present Value and a few other valuation methods can be seen here.

Risk-adjusted Net Present Value (rNPV) has been used in pharmaceuticals to determine if a capital investment is worth pursuing. The basic reason for the use of this method is that new medications are expensive… Expensive expensive. Like $2.5 billion expensive to get one for which the market approves. There is a high probability that drug trials won’t work out and the drug won’t make it to market on time or at all.  For that reason, risk of failure is assessed and applied to the valuation. That can lead to investment decisions in large capital projects.

How About Doing That In The Small?

With proper breakdown of strategy, I  encourage organizations to do some form of analysis for the next three months at a tactical level to make sure that they inform themselves of the level of risk so they can determine the likelihood that they will realize a return on their investment.  The risk exposure is smaller than NPV is usually concerned with and we may be willing to take on a larger risk profile, but the problem is the same.  If you have a relatively significant investment, you want a reasonable shot at realizing your return.

Looping in Agile

Take a look at programs and portfolios. Sure there are plenty of risks that can prevent projects or features from succeeding, but to keep it simple, I am focusing on the binary dependency. It is done or not done. Therefore, the probability of the risk being removed is 50%. Continuing the math for a bit, for each dependency on the outcome we target, we have a factorial of possibilities… or in English:

If we have two dependencies, we can have four possible outcomes.
For Example:

• Resolved | Resolved
• Resolved | Failed
• Failed | Resolved
• Failed | Failed

That makes the probability 25% that we will have an outcome of Resolved | Resolved.

If we have three dependencies you can have 8 outcomes and thus a 12.5% probability and so forth and so on. So now forget about NPV. We don’t care. We need a way to make good investment decisions for things that will actually come true. We also need this method to be lightweight.

Given 100 points are in a release and we have 2 dependencies that need to happen in order for us to release the features. We have  a 25% probability that we will release 100 points. Your risk to point value that you can count on is 25 points assuming that all points are blocked by those dependencies. Granted, that’s not a value assessment, it’s a point assessment. But that’s an ok place to start.

So Now What?

With this new information, there is a definitive incentive to remove risk early. Really early in the release. As a matter of fact, I want relatively new teams that are just starting out to plan a release that has an 80% certainty of delivering it’s value. That means that before the release, we need to remove most of the dependencies. I have been toying with capturing this as a risk burndown. Here’s a quick wireframe of it.

In this figure, we are burning down the percent of the release that is impacted by risk. Like I said, I like relatively new programs that hit 80% of their value delivery. We can use the percent impacted to drive risk points down to below 20% before the start. It’s a pretty simple, good way to look at the probability that programs and portfolios are making responsible commitments and have the math to back it up. Speaking of math… this stuff can get a ton more complex. A great goal is to keep it simple so we can all relate. I know this is a little off math wise, but it’s enough to inform and get people started toward developing reliable release plans and roadmaps that mean something.