Risk is encountered in all kinds of projects. The severity of risks can vary from low to high and is characterized by its probability and impact. Traditional predictive project management approaches have risk management embedded in its process. This usually happens during the planning stages of the project when the project sponsor along with the project team creates the project charter. Further risk management and control happens along with the project.
But how about Agile projects. Do we expect the same rigor and detail in managing risks? What does Agile risk management look like and how can it help teams get ahead of risks and successfully deliver? Let’s find out.
Risk Management in Agile
Given the iterative nature of Agile projects, many would argue that risk management is incorporated in each cycle. The heightened collaboration between product teams and business stakeholders allows Agile teams to adapt and still meet project goals despite risks. In essence, Agile project teams assess risk throughout the project lifecycle.
But this is not to say that Agile teams are immune to risks or are well-prepared for every kind of risk. This can greatly depend on the maturity of the team and the availability of project information. There might be risk factors such as external ones that the team may not plan for without dedicating time to flesh out the impending risks. In this manner, the lack of a proactive and structured Agile risk management framework can restrict flexibility at the onset of issues.
A structured Agile risk management approach can be beneficial for teams. This requires striking a balance between time spent on risk planning and doing actual work to manage risks. Agile approaches have processes and mechanisms in place for risk management. In Scrum, for example, we have the Daily Stand-ups and Sprint Planning as venues to discuss risks. The shorter increments also allow for faster customer feedback that ultimately manages the biggest risk – that is creating a product that doesn’t solve customer problems. We put a structure in the form of Agile risk management to ensure teams are looking into possible risks that their project can be exposed to and are proactively planning on how to address them.
While there isn’t a general framework for Agile risk management, we can certainly leverage tried and tested risk management methods used in predictive approaches, Kanban, and other Agile risk management tools and techniques.
The common risk management process involves the following steps:
- Risk Identification
- Risk Assessment
- Risk Treatment
- Risk Monitoring
Let’s explore each of these steps and how they are used in Agile risk management.
The first step in the Agile risk management process is identification. This can be done in a brainstorming session or incorporated in any of the planning sessions used by an Agile team. Here we recommend using the What-Why method as explained by Alan Moran. In the risk identification session, ask your project team what might happen – or the effects of the risks. Then analyze why they can happen – which concerns the causes of the risk and are the ones that need to be managed. When identifying risks, remind the team to keep an open mind in identifying both negative and positive risks. These positive risks can be opportunities that the team can take advantage of should they occur.
Keep this in a log or what we call a Risk Register. This will be the input to the next step in the Agile risk management process which is Risk Assessment.
The next step in the Agile risk management process involves analyzing the probability that the risk will occur and what its impacts are. Here, the team goes into assigning a value to quantify those risks. Mike Cohn proposed a way to quantify risks through a Risk Census, much like what a Risk Register is. Here we need to estimate the following:
- Probability – the likelihood of the risk event occurring
- Size of Loss – the impact of the risk event if it happens denoted by the number of days that would be lost
- Exposure – the Probability multiplied by the Size of Loss
The outcome of this assessment guides teams in risk prioritization and response planning.
Risk exposure calculated in the previous step enables teams to prioritize and plan how to tackle the identified risks. The PMBOK outlines 4 general strategies for responding to risk depending on whether they are negative or positive.
4 Risk Strategies for Negative Risks
- Accept – When the probability and impact are both LOW, teams may opt to accept the risk from materializing. This doesn’t mean though that the risk will be ignored. The team still needs to monitor the risk and see if it materializes to something much worse.
- Avoid – When the probability and impact are both HIGH, teams need to do whatever they can to avoid the risk. This may require performing certain activities that the team needs to do to eliminate the cause of the risk.
- Mitigate – When either the probability or impact is HIGH, teams can employ risk mitigation measures to lower the probability of the event from occurring, or to lower the impact of the risk if it ever occurs.
- Transfer – When the probability is LOW but the impact is HIGH, you may want to explore transferring the risk responsibility to another party. It could be a department within your organization or a third-party provider altogether depending on the risk.
4 Risk Strategies for Positive Risks
The risk response strategies for positive risks are opposites of the negative risk responses except for Accept. The remaining strategies are the following:
Exploit – When the probability and impact of the opportunity are both HIGH, teams must exert all efforts for it to materialize. This allows them to exploit the opportunity for their gain.
Enhance or Share – If an opportunity has a LOW probability of occurring, teams can explore to increase or enhance its probability of occurring by their own means. If this is unlikely, the project team may opt to share the responsibility with another party to capture the positive impact the opportunity brings.
In Agile risk management, the risk exposure scores can be used to plot a Risk Burndown chart. This allows teams to visualize just how much risk is present and how their tracking in terms of addressing those risks.
We should see risk drop linearly throughout the project. Otherwise, it means the team is not actively managing the risks they’ve initially identified. When this happens, the team should dedicate some time to risk management tasks for their next iteration.
Agile Risk Management with Kanban
Kanban is an effective technique to manage and surface risks in an Agile project. It can be built on top of any Agile method you’re using for product development and your subsequent Agile risk management process.
Here are some Kanban techniques that you can incorporate into your Agile risk management process.
Risk Modified Kanban Board
You can transform your usual Kanban board into a Risk Modified Kanban Board. This combines the value-adding tasks that directly relate to developing a product for an end-customer (e.g. user stories or feature enhancements) along with risk tasks that need to be performed to continuously deliver value. This allows teams to visualize just how much activities are attributed to risk management in an iteration.
The Risk Register contains the list of risks but prioritization and execution of risk tasks go to the backlog or the Kanban board. During Risk Treatment, teams can formulate a series of tasks that will help them manage threats and exploit opportunities.
Alan Moran, from the Institute of Agile Risk Management, prescribes teams to use risk tagging in their Risk Modified Kanban boards. Teams can use symbols to denote the team’s way of reducing risk for a particular task (e.g. pair programming, prototyping). Teams can also use color-coding of cards to denote which are requirements-related tasks, threats, opportunities, or contingency plans. This lets teams quickly see just how much risk activities there are and when they need to be performed. This helps in the overall execution of risk responses in an Agile risk management plan.
Kanban Classes of Service
Kanban classes of service provide structure and governance for how teams should handle incoming work while incorporating risk. This technique requires teams to classify the work before it enters their Kanban system based on a set of policies used by the team. There are four Classes of Service commonly used in Kanban.
- Expedite – These work items preempt other work and require teams to ensure no interruptions are experienced in the workflow. This is for critical and top priority items (e.g. production errors, server problems) that impede regular functions of a system or product.
- Fixed Delivery Date – These are work items that have a significant cost of delay, if not delivered on fixed delivery date. Items that fall under this class are prioritized where necessary to be finished on or before the target deadline.
- Standard – These are work items that solve business and customer requirements without a fixed timeline or sense of urgency. This is where a good chunk of the team’s work would normally fall under.
- Intangible – These are work items that are useful but do not have a significant cost of delay. Although non-urgent at the onset, teams should keep a close eye on these items as they become critical in the long run. Examples include optimization and quality improvements.
Using Kanban Classes of Service allows teams to apply adequate responses to issues and impending risks. You can refer to our Kanban Classes of Service page to learn more about this technique.
Successful Agile Risk Management
While there are innate risk management mechanisms in Agile methods, a formal Agile risk management plan can help project teams gain awareness and control of threats and opportunities. Involving the team and using visual techniques such as Kanban help establish risk awareness and push teams to become more proactive when it comes to Agile risk management. These techniques combined with a solid adherence to Agile principles help teams achieve success not only in risk management but in the delivery of their products and solutions as a whole.