Visual Risk Management

Interesting.
To visualize the (agile) risk management, you also have the "Agile Risk Board" to place on the information radiator too.
The description here:
www.agile-ux.com/2009/07/23/agile-risk-board/

Agile seems to have a strange relationship with risk. The reason I use Agile approaches is because they offer much more sophisticated tools for managing risk, namely real options. Given the level of sophistication of Agile I find it amusing that "best practice" for agile risk management is to create radiators.

Identifying a few obvious risks and displaying colourful graphics is not risk management (The equivalent of flying a flag up-side down). For each identified risk, you need to understand how long you have to recover from the realisation of the risk and then implement options to ensure you can recover in that timeframe.

Risk management is active. Its a discipline.

How long before people take risk seriously instead and look at proper risk management rather than simply displaying RAG status ( something that pointy haired management types have been doing for years ).

I humbly like to put forward a point that Agile techniques are a means to an end (Business Goals) there is a very thin line between doing Agile well and overdoing it. I for one am not a purist but a pragmatist.

e.g. One of our Global Financial Institution clients once told me "You cannot put up cards on the wall because thats not allowed but if you want I can give you touch screen LCD monitors, as many as you want and then you hook them up with Mingle" A wall is a priced commodity, lets use it carefully, every team need visualizations close to their area. How much of wall space do we intend to use?

This is the last thing I plan to put up there. I would rather putup things like cross project dependency walls, architect and analyst card walls, approval/deployment statuses if I had the freedom to.

My 2 cents.

Aditya Yadav
Aditya Yadav & Associates
Amazon Cloud Computing With C#/.Net
Amazon Cloud Computing With Java
Understanding Programming Languages
Deploying HTML5
Essays on SOA AND EAI - A Pocket Guide

IMO it's important to manage risks actively and continually as Chris points out. At the same time, I appreciate Aditya's advice to avoid overdoing things. I usually have a visual indicator of risks and their status in the team room. The article presents some useful formats, and there's another useful one based on the work of Lister and DeMarco. One example is here: www.agile-ux.com/2009/07/23/agile-risk-board/

I like simple tools that serve their purpose. Some of the approaches described in the article seem a bit complicated. I find a couple of rules of thumb useful for keeping things simple while still keeping up with risks:

1. At the team level, a "risk" is a potential blocker to delivery. Some teams dump a lot of other types of items into their list of "risks," like "We haven't used Oracle before," or "We don't understand the full scope of this feature set." Those aren't risks at all, they're just things to learn. So, one way to keep things simple and focused is to remove items from the risk board that aren't really impediments to delivery.

2. Don't think of risk cards in the same way as story cards. A risk should have an individual owner, a mitigation strategy, a proposed resolution, and a date by which the risk must be resolved or (at least) mitigated, contained, or avoided, as well as a Plan B in case that can't be done by the date. The impact from the Product Owner's perspective must be clearly communicated to everyone. But I haven't found any need to make it any more complicated than that.

After clicking submit I noticed someone had already posted a link to that other risk board. Sorry!

Real Options and agile are orthogonal.