There is too much uncertainty in agile projects can be misleading. There is much uncertainty about how exactly the product will function and what should be included in the product throughout the development and the final product. There is also some uncertainty about how the development work is to occur throughout the project. That does not mean that agile managed projects are complete free-for-alls with no order. If managed correctly, agile is not chaos, or even “organized chaos.” Agile projects have the same risks as traditional projects. What the risks are and how they are dealt with may differ, but the risk quantities and significance are similar, as is the processes dedicated to manage risks.
Project risks, regardless of whether they are risks of an agile project or a traditional project, are uncertainties. If you are uncertain whether an event, action, or result is going to happen or not, then that, in its simplest definition, is a risk. If you aren’t sure about how much damage a risk could cause, that uncertainty is also part of the definition of “risk.” Based on those two factors — the probability or likelihood of something occurring, along with the amount at stake or its impact if the event or condition were to occur — you can begin to see how both project types could hold equal volumes of risk. The precise volume of risk is more relative to the project, not to the project management approach.
The uncertainty is identified in a similar way in both traditional and agile projects. There are uncertainties everywhere in projects. To clarify, just because you are uncertain about the outcome does not necessarily make it a risk. What is a risk is how uncertain events or conditions impact your project. The non-project example I like to use is: on a certain Saturday, the Seattle Sounders MLS soccer team is playing. I am uncertain if they are going to win. Is that a risk? No, not technically. What if I place five dollars on the outcome, is there risk then? Yes.
Remember, risk is a combination of the likelihood of an event or condition occurring or not occurring, and the impact that outcome has.
The equation for determining the severity of risk is to multiply the probability times the impact. In our app project, if we have identified the risk of the communication between our server securely hosting our employee data and our application failing to connect as likely to occur, and if it does fail, then the impact is catastrophic because the app is useless without the secure data. Our calculation of high probability times high impact would indicate that this risk poses a very high risk severity.
That assessment consists of our impressions at this point with the information we have available. Risk probability and benefits and consequences of risks are not static. The severity of risks may increase or decrease based on the actions we are proactively taking or for factors unrelated to our actions. To graph the various identified risks fluctuations over time, we have our risk burndown graph. Our efforts in dealing with or managing risks can be shown by a decreasing line — like in this example, where our constant testing of the connection is bringing the likelihood of a connection failure less and less likely. Another case of identified risk on our burndown graph is the login process displaying a spiked increase because we learned that an update to the mobile device’s operating system has created doubt in the effectiveness of the login process. Again, I created these two examples to illustrate that risk severity can change over time. The assessment and reassessment of risks over time is important.
Imagine that there are two different interpretations of the severity of the risks we identified in our project. Jamal, in our project, knows a lot about servers and is stressing the high probability of the connection not working. However, Jane has implemented similar apps at previous companies and has never experienced any issue. She is arguing that the likelihood of any issue is remote and the severity is low. How the risks are assessed can be based on subjective information like expert judgment and analogous data. This is referred to as “qualitative risk assessment.”
If you need more than opinions of risk severity, than quantitative risk assessment may be in order. As the old adage goes: “Money talks and nonsense walks.” There may be a need to use hard numbers, and in some cases, monetary values. For instance, having you tell me that “the server could get overloaded and it could be kind of bad once it does,” is not as meaningful as “Based on our calculations of highest usage, the servers might fail 85 percent of the time during those peak periods, and when it is down, there is a net loss of $1,000 per minute.” I did keep the numbers to the potential damage really low because it is only our internal employee app after all. But I also wanted to keep the numbers simple to show you an equation you could commit to memory for expected monetary value.
The expected monetary value calculation takes into consideration the three things that make up a risk:
- the event or condition
- the probability or likelihood of it occurring
- the impact if the risk is realized
Therefore the equation is simply: risk expected monetary value = risk probability times impact. You might be thinking, isn’t that the same equation we had for risk severity? You are correct. The only difference now is that there are real numbers behind it. Dollars, or whatever currency being used.
In our example, the expected monetary value, or EMV, of the risk is 85 percent times one thousand. That equals 850 dollars.
Knowing that the risk is valued at the possibility of losing or incurring the consequences of 850 dollars provides a different assessment than our qualitative assessment of “high” times “high” equals “really high.” We can use the 850 dollar value in a few ways. One way would be to consider the response plan.
Maybe the development team can provide some load balancing during the peak periods at a cost of 400 dollars. Investing 400 dollars to mitigate an 850 dollars per minute consequence might seem like a logical move. In another case, there may not have any way the team can mitigate or avoid the risk. The risk might be one that the team must accept as “the price of doing business.” In this case, the 850 dollar’s value may simply need to be a monetary amount to be put aside in a reserve to handle the risk if it ever does rear its ugly head. Those are just two examples of how expected money values can be used in managing agile projects.
An example of responding to the risk is repairing our server peak periods risk to incorporate more load balancing. There are proactive measures that can be taken to reduce the risks and there are reactive ones. The more desired method in most considerations is using the proactive ones — unless the cost of doing so is greater than the risk, for instance.
Risk in agile projects should decline over time as the project progresses. This is because in agile projects, failures happen more at the beginning. Fail early and often, so that there are less failures later. Likewise, gaining customer input from the start and in every iteration, the risks are more upfront and proactively worked against.
When efforts are taken to reduce the probability or impact of a risk, it is called mitigation. Mitigation means to lessen or reduce. Mitigation does not completely remove the risk at the start, but can minimize its consequences or reduce the chances of the risk being realized.
Another risk response strategy is to avoid the risk altogether. An example of avoidance would be to adapt your plans to completely remove an element that is considered risky. So if our expectations are that the app would accept a payment system, but upon our analysis we determine many risks in doing so. Thus our decision to remove any payment processing and systems in the plans avoids the associated risks altogether. That is a generic example of the risk avoidance strategy.
Whatever risk responses are utilized, the importance is to identify those risks early and actively work towards mitigating or removing them.
Leveraging the efforts of agile project risk management, the product artifacts, especially the product backlog, should be adjusted based on the information. The knowledge gained should be applied to ensure the project can move forward accordingly.
Risk Burndown Charts
A fair question one might ask of you as project manager of an agile project is “Are you making any progress against the risks and how you planned to manage them?” Communication is important. So is working to eliminate or minimize the negative impact of project risks. Communicating to demonstrate our active pursuit of handling risk speaks volumes. One powerful tool is a risk burndown chart. A risk burndown chart or graph communicates the team’s progress of “burning down,” removing, or calming the probability and impact of your identified risks. It is one thing to simply list the risks we have identified and how we feel about them; it is another to show that risks are being addressed, and in some cases, no longer an uncertainty having any impact to the project.