Agile risk management describes the integration and adaptation of risk management techniques into Agile projects in a manner consistent with Agile principles and practices. But sometimes, it is the very notion of risk itself that poses challenge for Agile team members. I usually find it helps to equate risk with uncertainty that impacts project objectives, so consider this definition to take a practical look at how Agile teams identify risk. My recent Journal article, “Risk Management in Agile Projects,” uses the example of the migration of a web server to explore the confusion that arises between risk and effect. The article then introduces the what/why technique in order to derive risk (why) from effects (what), so that risk managers can derive appropriate courses of action.
I usually perform risk identification during the planning session at the start of each iteration. I start with the "what" question by asking everyone in the team to write down outcomes that may materially affect the outcome of the project. Each outcome should be written down on a separate piece of paper. This activity can be facilitated in a group session or done individually (in which case you will need a little time at the end to sort out duplicates or eliminate outcomes that are not really that relevant). I have to be careful here not to ask what might go wrong, but instead keep the discussion open to embrace opportunities too.
Next, I turn to the "why" question to discover why each outcome might occur. This can be done either in a group discussion or using a round robin approach of passing each piece of paper around the team giving everyone 1 minute to write down their responses. The key here is to watch out for expressions of uncertainty (e.g., "not sure," "unclear," "must find out") since these responses may indicate the true sources of risk.
Using the web server migration example from the article, we might have discovered in the "what" round that the server might not be available after the migration (recall this is an effect, not a risk). We write this down on a piece of paper and in the "why" round we discuss how this might have occurred. Here we might encounter statements such as "I am not sure how to reconfigure the domain name system (DNS)" or "I cannot be certain that the virtual configuration is the same as the physical one." These are the real risk factors on which we need to focus. We use these not only to help us assess (and, therefore, priortise) risk more accurately, but also to identify sensible risk tasks (e.g., read a chapter on how to configure DNS) or risk tags (e.g., perform configuration in pairs) that can meaningfully reduce the overall risk in a project.
Read Alan Moran’s recent Journal article:
“Risk Management in Agile Projects,” ISACA Journal, volume 2, 2016.