Trying to maximize business value while ignoring risks is a little like trying to heat your home with all the doors and windows open. Much harder work than it need be, unlikely to be successful, and just not very smart.

Risks and opportunities are ever present on complex projects. We can rely on them occurring much like we can rely on the tide coming in. How we choose to deal with them--our risk management strategy--greatly influences whether we rise with the inevitable tide of issues and navigate successfully, or become overwhelmed by them and don’t reach our goal.

Agile methods incorporate many mechanisms for dealing with late-breaking changes (an easily reprioritized backlog, short iterations, frequent inspection, replanning, etc.) that also lend themselves to proactively responding to risks. We can insert risk avoidance and risk reduction actions into the backlog to attack the risks before they have an impact on the project.

This can all be thought of as part of maximizing business value. The process of frequently asking: “What should we do next: build a business feature or reduce a project risk?” is valuable and often summarized by the term “The next best dollar spent.” It reminds us to think about risk avoidance and mitigation as part of the value proposition and agile planning cycle.

So when planning work for the next iteration, we balance delivering business value with reducing risks. Sometimes we select a feature since it is the best return on our investment; sometimes we will undertake a risk avoidance or risk mitigation step since the impact of the risk occurring would be greater than the ROI value of the next feature in the backlog. (This is a quick summary; to read more about putting risk reduction actions in the backlog see here.)

Over the course of the project, agile teams use tools such as risk burn-down graphs and risk profiles to illustrate the effectiveness of the risk-driven approach. The goal is to rapidly reduce risks on the project. (For more on these agile risk reduction techniques, see here.)

Another benefit of tackling risky work early is the cost of change-curve savings possible in software projects. By proactively undertaking risky work early, we can reduce the overall impact to the project compared to if those risks occurred later when their effect (in terms of rework or revision of approach) would be much higher. Simply put, risks solved early are more valuable than risks solved late.

Agile methods with their pull mechanisms and frequent reprioritization can readily take risk management actions as early as possible in the lifecycle, minimizing knock-on effects. Also, since testing is built into each iteration, toward the end of the project the chances of there being any risky elements not tested in the solution are greatly reduced. As such, agile methods can be called “risk-driven” since we are always looking to pull stories with risks forward in the backlog.

While agile methods provide some nice ways to proactively embrace good risk management practices, they do not “risk-proof” nor insulate projects from risks. Indeed, if the agile approach is new to your organization, then its introduction will be a risk itself--anything new represents a risk of misapplication, misunderstanding, confusion and failure. However, agile methods are hardly new anymore and adoption problems are well understood.

This post introduced how agile methods mesh well with the mechanics of risk management. Next time we will examine the next level of effectiveness in agile risk management: how engaging the team members in risk management through collaborative games brings far greater insight into project risks, and their avoidance and mitigation actions.

(Portions of this post first appeared in Gantthead.com here)