Agile Risk Management – Harnessing the Team
Calgary Presentation - Working Effectively with Off-Shored IT Resources

Collaborative Games for Risk Management

Team_solutionsThis is the third part in a series on agile risk management; Part 1 looked at the opportunities agile methods offer for proactive risk management, while Part 2 examined the benefits of engaging the whole team in risk management through collaborative games and cautioned us about groupthink. This article walks through those games and explains how to engage a team in the first three of the six risk management steps.

The PMI risk management lifecycle comprises of:

  1. Plan Risk Management
  2. Identify Risks
  3. Perform Qualitative Risk Analysis
  4. Perform Quantitative Risk Analysis
  5. Plan Risk Responses
  6. Control Risks

These phases can be addressed collaboratively via the following team exercises:

  • Plan Your Trip (Plan Risk Management)
    • 4Cs: Consider the Costs, Consequences, Context and Choices
    • Are we buying a Coffee, Couch, Car or a Condo? How much rigor is appropriate and what is the best approach?
    • Deposits and Bank Fees – understanding features and risks
  • Find Friends and Foes (Risk and Opportunity Identification)
    • Doomsday clock
    • Karma-day
    • Other risk identification forms (risk profiles, project risk lists, retrospectives, user story analysis, Waltzing with Bears - Top 5-10 for software)
  • Post Your Ad (Qualitative Risk Analysis)
    • Investors and Help Wanted – classification and visualization of opportunities and risks
    • Tug of War – project categorization
  • Today’s Forecast (Quantitative Risk Analysis)
    • Dragons Den – next best dollar spent
    • Battle Bots – simulations
  • Backlog Injector (Plan Risk Responses)
    • Junction Function – choose the risk response path
    • Dollar Balance – risk/opportunity EVM to ROI comparison
    • Report Card – customer/product owner engagement
    • Inoculator – inject risk avoidance/mitigation and opportunity stories into backlog
  • Risk Radar (Monitor and Control Risks)
    • Risk Burn Down Graphs – tracking and monitoring
    • Risk Retrospectives – evaluating the effectiveness of the risk management plan
    • Rinse and Repeat – updating risk management artifacts, revisiting process

We will walk through the first three steps in this article and then the last three steps next month:

1. Plan Your Trip (Plan Risk Management)
This phase is about deciding and defining how to conduct risk management activities for the project. We want to tailor the process to ensure that the degree, type and visibility of risk management is commensurate with both the risks and the importance of the project to the organization. So we do not use a sledgehammer to crack a nut, or undertake a risky, critical endeavor with an inadequate process.

The other goal we have for this phase is to teach some risk basics to the team since they may not be familiar with the concepts or terminology. The name of the first exercise (“Plan your trip”) speaks to the goal of determining the appropriate level of rigor. Most people can associate with planning for a walk or hike, and this is the context we use for the activity called the 4Cs. Early in any collaborative workshop, I like to get people working. If you let them spectate for too long some will retreat into “observer” rather than “participator” mode.

Working individually (again to encourage active engagement, and avoid groupthink), ask the team to consider what they would pack for a two-mile hike in the country on a warm day. Give them a couple of minutes to create lists on Post-it notes and review their responses as a group. Some will suggest taking nothing, others just a bottle of water, rain jackets, bear spray (I live near the Rocky Mountains in Canada) and all sorts of other things. We then review the pros and cons of these items. They are useful if you need them, but a burden to carry. We then repeat the exercise changing some parameters such as making it a 10-mile hike or a multi-day trip in the mountains during winter. Now the lists get longer as people prepare for more eventualities.

For each situation, we review the 4Cs: the Costs, Consequences, Context and Choices. What we bring (and how we prepare for risk management) varies based on the cost of bringing/using it, the consequence of not having it (rain coat: get wet; warm jacket : cold/hypothermia). We also examine the context we are talking about: preparations for elite ultra-marathoners who are hardy, capable and resourceful, or a kids’ group that needs more protection. Finally, the choices we make should be an informed balance of cost versus consequence in the frame of the context.

We need to understand these same elements in planning our risk management approach, too. Is this project domain our core competency? What are the costs and consequences of project risks occurring? What is our company’s risk tolerance and preferred risk management approach? Make sure people understand the environment.

Another tool to relate the need to tailor the process appropriately is to ask the team to consider the decision rigor they put into their purchases. The way we consider buying a coffee ($2), a couch ($2,000), a car ($20,000) or a condo ($200,000) varies as the figures involved escalate. For a coffee, we probably just find something close, maybe at our favorite store. For a couch, people will shop around and likely buy the one they like the best without much further research. When it gets up to car territory, safety, economy and resale factors are routinely examined. For a condo purchase, the stakes are so high that most people engage professional help from home inspectors and condo document review companies. We need to do the same for our projects, asking what is appropriate for the endeavor.

Finally, if the team is new to risk management then a discussion on the tradeoff between business value and risks might be necessary. We undertake projects usually for the potential upside (or for compliance projects to avoid the downside)--we are hoping for business benefits. Agile projects use business value as an input into work prioritization; we do the high-value items first. We want to deliver business value, and getting business value out of a project is like receiving deposits into our bank account--we want them as often as possible, and preferably as large as possible. Given the uncertainty in the world, we want the biggest gains as soon as possible before anything changes that may threaten future deposits.

In this bank analogy, risks are like withdrawals or bank fees--should they occur, they set the project back, take away resources from delivering business value and threaten the delivery of future value. So to get the most out of a project we need to maximize business value while avoiding or reducing risks. These exercises and discussions aim to get the team thinking about the appropriate level of risk management for the project and gain consensus and support for the strategy that is agreed upon. Without this shared understanding of “Why?” we will not get people invested in the process.

2. Find Friends and Foes (Risk and Opportunity Identification)
The next step in the process is to identify potential risks and opportunities. Opportunities are the “good” risks or fortuitous events that have a positive impact should they occur. We want to avoid risks and exploit opportunities. The IEEE have some good risk profile models for software projects. They were created by collecting risk information from thousands of completed software projects, then categorizing and ranking the common ones. These models can be used in a group setting or, as I prefer, used as the inspiration for a collaborative game. The “Doomsday Clock” exercise is based on a risk profile tool I have written about previously.

Using a clock view pre-drawn on a white board or flip chart, we ask team members to think of project risks associated with each of the topics represented by an hour line on the clock--12 in total. (For a detailed description of the types of risks within each category we would be asking the team to identify, see the spreadsheet attached to the risk profile article.)

This is the doomsday part: Wwe encourage the team members to think of and record as many risks as they can about that topic. We work topic by topic, but if thinking of risks triggers ideas in other areas as we progress, it is not unusual to get risks being added to previously discussed risk lines. Again, I prefer having people working individually for coming up with ideas. Then we put them all on the wall and consolidate and remove duplicates as a group, which also sometimes identifies new risks.

This process takes a while; spending just five minutes on each topic requires an hour to go through them. Discourage people’s tendencies to want to score, rank and solve the risks. This is risk identification--we will have plenty of time to process them later.

Doomsday Clock

A wall filled with risk stickies around every aspect of the project can seem like a discouraging prospect for some, but it is also a useful eye opener for why risk management is so important. This project is not magically going to work out all by itself.  We have some real obstacles in front of us and we need to work as a team to avoid and reduce them.

Always within the same session, I like to run the flip side exercise: “Karma Day”. In this exercise we generate opportunities for events and outcomes that would assist the project, creating ideas for things that would help the project go well. Using the same clock metaphor, we come up with lists of all the good things that could occur to assist the project.

Cynical team members may still continue to gripe, suggesting opportunities “inverted issues” such as “actually getting a one- to two-day turnaround on our database requests, for a change” or “no resistance from the PMO”, but these can be really useful. Just as we later ask in risk management, “How do we avoid or reduce these risks?”, in opportunity management we ask, “How do we ensure or maximize these opportunities?” If spending a couple of hours explaining the project goals and approach to supporting groups--or proactively asking them how we might best engage with them--makes a difference, then this work could have a huge return on the time invested.

Without asking the team for a list of all the good things that can happen, team leads and project managers will likely be unaware of all the ways in which they could serve and support the team. The ScrumMaster as an “obstacle remover” is a one-sided, glass-half-empty view of the world. Why not explicitly add “opportunity implementer” to the job description and let’s see if we can arrange some mutual wins by being proactive?

Karma Day

These techniques are facilitated games for identifying risks and opportunities, but they do not stop us applying more conventional approaches, too--such as risk profiles, project risk lists, SWOT analysis, retrospective findings, user story analysis, etc. Let’s not throw out the baby with the bath water; still use traditional approaches, but augment them with team-based approaches for better insights and buy-in.

3. Post Your Ad (Qualitative Risk Analysis)
Having found risks and opportunities, we now need to classify and rank them. The duplicates found in Doomsday Clock and Karma Day can be removed and related risk and opportunity ideas might be better consolidated under new headings (provided they truly are the same risks). Then we need to categorize and prioritize them. The traditional way of doing this is to assign numeric probability and impact scores using something like the PMBOK-inspired matrix shown below. While mathematically valid, some people find it counter-intuitive that the highest-ranked risks are grouped right next to the highest-ranked opportunities since they represent opposite extremes of bad and good outcomes for the project.

Another issue with assigning estimated probability and impact values is that people are much better at relative estimation rather than absolute estimation. We get hung up on whether something has a 0.7 or 0.9 chance of happening, but could tell you that it is more likely that the lack of C# experience will bite us before a lack of MSBuild experience will. This is one reason many agile teams use effort estimation based on points rather than ideal days, and we give directions in reference to landmarks rather than pure distances. People are better at relative estimation than absolute estimation.

So recognizing these human traits, I prefer to get teams to gauge impacts and probabilities in a more intuitive and relative way. For this we use “Investors and Help Wanted” board concepts. Risks are things we need help with, opportunities and things we are seeking investors and supporters for. Using scales of impact to the project in terms of impact (costs for risks; benefits for opportunities) on the X axis and probability of occurrence on the Y axis, the risks and opportunities can be visualized by the team as shown below.

Investors and Help Wanted

In this layout, the X axis of impact to the project in terms of benefits and costs creates a spread where the greatest opportunities are furthest removed from the greatest risks. We do not worry too much about numeric analysis of probabilities, but instead use relative ranking to determine the vertical positions. The benefits at this stage really come from the conversations amongst team members about analyzing the risks and opportunities and gaining consensus as to where they belong relative to each other on the charts.

Visualizing and agreeing on a spatial reference for the risks and opportunities also engages the right hemisphere of the brain and makes us less likely to forget them. (Assigning things we want to remember to a location is a memory aid that many memory-improvement techniques use. Probably relating back to our hunter/gatherer days when our survival relied upon remembering where to find food and water, we have better recall of things assigned a physical location.) This is useful for us as the project progresses since if we better remember the risks and opportunities at play, we are more likely to tailor our behaviour and everyday decisions toward them appropriately.

This month’s article has described how we can engage team members in the process of better understanding risk management concepts and then engage them in the identification and analysis of project risks and opportunities. Next month’s article will outline the team-based collaborative games for the remaining three stages of risk management:

  • Today’s Forecast (Quantitative Risk Analysis)
    • Dragon’s Den – the next best dollar spent
    • Battle Bots – simulations
  • Backlog Injector (Plan Risk Responses)
    • Junction Function – choose the risk response path
    • Dollar Balance – risk/opportunity EVM to ROI comparison
    • Report Card  –  customer/product owner engagement
    • Inoculator – inject risk avoidance/mitigation and opportunity stories into backlog
  • Risk Radar (Monitoring and Control Risks)
    • Risk Burn-Down Graphs  –  tracking and monitoring
    • Risk Retrospectives  –  evaluating the effectiveness of the risk management plan
    • Rinse and Repeat  –  updating risk management artifacts and revisiting the process

Finding and categorizing risks is a start, but not sufficient. The real value comes from converting them into actionable stories for the prioritized backlog, then tracking and adapting based on review and reflection of the system’s effectiveness. These are the topics we will be examining next month when we delve into games like “Inoculator” and risk burn-down graphs. So be sure to check back for the final set of team-based collaborative games for agile risk management!

(This post first appeared in here)


julio caldas

Great article Mike.
I´ll wait anxiously for second part.


The comments to this entry are closed.