With the craze of many companies and organizations, big and small to jump onto the Agile bandwagon, a few areas of traditional Software development get ignored or trivialized. More often than not, these come back to bite us late in the cycle. In true Agile fashion, teams then scramble to do the best they can to get the product over the line.

One such area of Software Development that sometimes gets overlooked is Risk Management. Traditional Risk management had projects following either the qualitative or the quantitative approach to Risk management. Detailed risk mitigation would be then put in place to ensure that the Risk was well handled. Many times, this placed a considerable overhead on the team.

Agile teams following the Scrum or XP model inherently embed Risk Management. Risks would typically be identified when the team throws up impediments in the daily standup OR fails to meet its Sprint commitment (because of a story being more complicated or having a dependency that failed to fall in place). Whatever the reason may be, Agile teams are pretty good in throwing up Impediments quite early. These impediments could turn into significant risks, more so when they involve external stakeholders and other teams.

In view of keeping the processes light weight, Agile methodologies are not prescriptive about how the risks can be made visible or managed. From a management perspective, the PMO or Senior Management might see this as a flaw in the Agile methodology since they do not get enough visibility about the risks and hence unable to step in at the right time to clear the path.

In such a scenario, here are some tips that would help.

• If using an electronic tool like Jira or Rally, raise a work item of type ‘Risk’, provide a severity rating to it and put a Blocked status onto it. Assign them to the right stakeholder and publish a weekly list of these risks to the management. Note: Make sure that the key stakeholders have access and are watchers to these risks.
• If using a physical board, create a 3 x 3 Risk matrix (Probability(L,M,H) vs Impact(L,M,H)) on the physical board, put up the risk and assign the stakeholder’s avatar to it. Take a snapshot on a weekly basis and send it out to the management stakeholders.
• Report your blocker in the Scrum of Scrums meeting, explain the potential consequences and nudge the management to take action (mitigate, avoid or accept).

In short, the key to an effective Risk management in an Agile world is to make it highly visible, accountable, time bound and easy to action upon.

Are there other light weight and effective Risk management practices that your Agile team follows ??
Do let us know..