Agile Risk Management – Harnessing the Team
Last month we looked at how agile methods provide multiple opportunities for embracing proactive risk management. The prioritized backlog, short iterations, frequent inspections and adaptation of process map well to tackling risks early and checking on the effectiveness of our risk management approach.
We want to overcome many of the correct-but-not-sufficient aspects of risk management seen too often on projects:
Poor engagement - dry, boring, academic, done by PM, does not drive enough change
Done once – typically near the start, when we know least about the project
Not revisited enough – often “parked” off to one side and not reviewed again
Not integrated into project lifecycle – poor tools for task integration
Not engaging, poor visibility – few stakeholders regularly review the project risks
This month’s article extends risk management beyond the project manager role and introduces the benefits of making it more of a collaborative team exercise. Next week we will walk through the team risk games one by one.
First of all, why collaborative team games? Just as techniques like Planning Poker and Iteration Planning effectively make estimation and scheduling a team activity and gain the technical insights of engaging people closer to the work. So too do collaborative games for risk management; after all, why leave risk management to the person who is furthest from the technical work – the project manager?
"...why leave risk management to the person who is furthest from the technical work – the project manager?"
Before I upset project managers worried about erosion of responsibilities we need to be clear on what the scope is here. I am advocating the closer and more effective engagement of the team members who have insights into technical and team related risks. I am not suggesting we throw the risk register to the team and tell them to get on with it. Instead we are looking for better quality risk identification and additional insights into risk avoidance and mitigation, not the wholesale displacement of the risk management function.
So why should we bother to engage the team? Why not let them get on with doing what they are supposed to be doing, namely building the solution? Well there are some reoccurring problems with how risk management is attempted on projects. Most software projects resemble problem solving exercises more than plan execution exercises. It is very difficult to separate out the experimentation and risk mitigation form the pure execution. Team members are actively engaged in risk management every day. We can benefit from their input in the risk management process and if they are more aware of the project risks (by being engaged in determining them) how they approach their work can be more risk aware and successful.
The benefits of collaboration are widely acknowledged, a study by Steven Yaffee from the University of Michigan cites the following benefits:
1. Generates wiser decisions through the understanding of complex, cross boundary problems via shared information
2. Promotes problem solving rather than procedural decision making
3. Fosters action by mobilizing shared resources to get work done
4. Builds social capital by building relationships and understanding
5. Fosters ownership of collective problems by valuing participation and shifting power downwards
There are some powerful concepts here that are worth a second look. It is pretty obvious that engaging a larger group of stakeholders will produce a better list of possible risks and then yield more creative ways of avoiding or reducing those risks. However the real benefits of engaging the team come from the changes that happen in the team.
By engaging the team not only do we get better input data and ideas, but we also encourage problem solving, foster action, build social capital and foster collective ownership of ideas. No longer do we have a single project manager worried about the risks, we now have a motivated, energized and empowered team proactively managing the risks.
"...we also encourage problem solving, foster action, build social capital and foster collective ownership of ideas."
Far too often projects do a great job at indentifying possible risks and a lousy job doing anything about them. The result is projects that get derailed when a known risks becomes an issue. When the team is fully plugged into the project risks, small changes in their behaviour eliminate many risks at their source, long before they get large enough to threaten the project.
Finally the last point in Yaffee’s benefits of collaboration list is noteworthy too. Valuing participation and shifting power downwards fits extremely well with the empowered teams and servant leadership model promoted by agile methods. We already encourage these ideas in reporting progress via daily stand-ups, estimating via planning poker, and decision making via fist of five techniques, so why not in risk management?
Of course collaboration is no silver bullet. Like all good approaches there are downsides and potential for misuse. Brainstorming for example can actually stifle innovation and lead to groupthink. This recent InfoQ post has a nice summary of the downsides including research on how brainstorming groups think of fewer ideas than the same number of people who work alone and later pool their ideas. So, let’s be clear, collaboration, does not only mean brainstorming, it also includes pooling individual ideas.
Before wrapping up this article we will review the PMI risk management process and look at the list of collaborative team games that map to the phases.
The PMI’s latest guidance on risk management comes from the PMBOK v5 Guide Exposure Draft, it describes a six step process for risk management:
1. Plan Risk Management
2. Identify Risks
3. Perform Qualitative Risk Analysis
4. Perform Quantitative Risk Analysis
5. Plan Risk Responses
6. Control Risks
Through collaborative games each of these 6 risk management steps can be recreated as highly visual, team based activities that then create risk avoidance and risk mitigation stories for the product backlog.
We want visual collaborative games because visual representation helps engage the left and right hemi-spheres of the brain. They allow us to tap into our spatial awareness and memory to avoid forgetting about risks. This is the reason today’s military still use visual tokens to represented enemy forces, despite having access to the world’s most sophisticated tools. The impacts of forgetting about them can be fatal. The same goes for project risks.
The collaborative games that cover these steps are:
1) Plan Your Trip – (Plan Risk Management)
a. 4Cs - Consider the Costs, Consequences, Context and Choices
b. Are we buying a Coffee, Couch, Car, or a Condo? How much rigor is appropriate and what is the best approach?
c. Deposits and Bank Fees – understanding features and risks
2) Find Friends and Foes – (Risk and Opportunity Identification)
a. Doomsday clock,
c. Other risk identification forms (risk profiles, project risk lists, retrospectives, user story analysis, Waltzing with Bears - Top 5-10 for software)
3) Post Your Ad – (Qualitative Risk Analysis)
a. Investors and Help Wanted – classification and visualization of opportunities and risks
b. Tug of War – project categorization
4) Today’s Forecast - (Quantitative Risk Analysis)
a. Dragons Den – next best dollar spent
b. Battle Bots - simulations
5) Backlog Injector – (Plan Risk Responses)
a. Junction Function – choose the risk response path
b. Dollar Balance – Risk / Opportunity EVM to ROI comparison
c. Report Card - Customer/Product owner engagement
d. Inoculator – inject risk avoidance/mitigation and opportunity stories into backlog
6) Risk Radar – (Monitoring and Control Risks)
a. Risk Burn Down Graphs - Tracking and monitoring
b. Risk Retrospectives - Evaluating the effectiveness of the risk management plan
c. Rinse and Repeat - Updating risk management artifacts, revisiting process
Check back next week for a walk-though of how to use these exercises on agile teams for enhanced buy-in, insight, and intelligence towards proactive risk management.
(Portions of this post first appeared in Gantthead.com here)