Vanilla Agile Risk Management flavored with some traditional practices

In traditional risk management process, a complete list of potential risks with their priority and a plan to mitigate them is prepared upfront. A lot of time and effort is spent towards these hypothetical risks both in upfront planning and in ongoing monitoring and discussion.

While in Agile, the process is rather emergent in nature. The realization of risk occurs quickly and abruptly. Team gets a sense of it at the earliest possible stage, delay time is less as the risk gets highlighted in the daily stand up, review, retrospectives or release/sprint planning meetings. It is more a real time thing in Agile. But are an application of these Agile practices enough to manage risks in an Agile bound project? Or with little adjustments can the traditional risk management be more powerful with Agile methods?

Lets see how the best of both worlds can be combined for an effective risk management in an Agile project.

Whatever I'm going to explain below is a summary of my experimentation, something that has worked for me and may or may not work for all of us. Please have a look and let me know if you find it useful.


So, How Did I Do It?

•Embraced bare minimum traditional risk management techniques
•Customized it with core Agile principles to make it a lightweight framework
•Applied Agile principles to avoid self creation of intrinsic risks or uncertain events
•Implemented DAD (Disciplined Agile Delivery) framework's approach to identify potential risks in the Inception phase of a release
•Used Product Backlog to manage risks
•Included Story Risk Review as a part of DOR (Definition Of Ready)

Risk Defined: 

Risk is uncertainty that matters, i.e, uncertainty that if realized impacts one or more objectives in either a negative (threat) or a positive (opportunity) (Dr. Alan Moran)

Risk is generally assumed to have a negative impact however it can have a positive impact too, also referred as opportunities. The intention should be to reduce the impact of negative risks, while for positive risks one should try to increase the likelihood of the risk to happen.

Like traditional Risk Management, it is a four step process:

1. Risk Identification:

When: Release Planning, Backlog
grooming , Sprint Planning, Daily Stand Up, Sprint Review.

How: A set of predefined/adhoc questions, discussions

Following is the Risk Breakdown Structure and few example questions that may be a part of the discussion:

Technical Risk- Is User Story well defined with all the open questions answered? ACs clear? Any Technical Challenges? DOD/DOR defined?

Business Risk- Customer Needs Identified? Competition? Business Benefit clear? Economy

Security Risk- Is the solution adequately protected from intruders. Questions that address security aspects, negative attacker stories.

Project Risk- Schedule / Budget Constraints? Availability of resources? Distributed Team, Dedicated PO? Etc etc

Organizational Risk- Politics, Stake holders, Virtual Team etc

Who: By the team, though the ownership is of the Product Owner

2. Risk Analysis 

Risk Analysis is done by deriving following:

-Probability (Likelihood of happening it)

-Impact (Cost, Schedule, Technical Performance, Reputation etc)

-Exposure is the quantified potential for loss that might occur as a result of some uncertainty (Multiplication of Probability and Cost)

3. Address Risk 

Release Risk Register: As suggested by Scott Ambler and Mark Lines in their ground breaking book- Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise  risk list or risk register should be created in the Inception phase of every release and used as part of the prioritization criteria for work items. This is maintained throughout the project, a sample release risk register may look something like this:

Description	Probabaility	Impact	Exposure	Response	Sprint
New features may require significant rework and skills	4	3	12	Technical Spike - US2031 created for investigation	Sprint 11
Database Scalibility	3	2	6	Pending
Potential security flaws discovered	4	5	20	Security task created. TA2045	Sprint 11
Third party Integration challenges	3	2	6	Neha to sync up with Akamai team to figure out discrepancies and challenges	Sprint 12
Video streaming schedule slipping - Technical challenges	2	4	8	Manav and Chris to pair program to fix it. Task-TA2037	Sprint 13

Probability and Impact are measured on a scale of 1-5 with an explicit definition of what a 1,2,3,4 and 5 means.

Exposure is a multiplication of two. 

4. Risk Monitoring

Risk Modified Kanban Board: It is a visual indicator to track the risk responses. Corresponding responses are tagged with the respective tasks. There are three columns -response Planning, In Progress  and Done. The generic Kanban board is modified to monitor the progress of risk tasks as well.

Release Risk Burn down Chart: 

Risk Management activities in various meetings:

Framework

Risk Register Update:

In sprint review, PO reviews the risks and takes a call on the residual ones, if any. Risk register is updated accordingly. 

Summary:


•Embraced bare minimum traditional risk management techniques
•Used Scrum meetings to discuss risk
•Prepared the Release Risk register and added risk response as a separate task/story in the product backlog or as a sub task of a user story
•Included Story Risk Review as a part of DOR (Definition Of Ready)
•Like ordinary tasks, modified the Kanban board to track risk.
•Used Risk Burn down chart for a sprint/release

I hope this article helped you in getting an understanding of how with little adjustments can the traditional risk management be more powerful with Agile methods. I will also recommend Dr Alan Moran's book 'Agile Risk Management', it is such a good read and you may find it here http://www.amazon.com/Agile-Management-SpringerBriefs-Computer-Science/dp/3319050079

Let me just caution you that there is no prescription to it. I explored, failed, innovated, adjusted and eventually succeeded. However I strongly recommend to follow DAD (Disciplined Agile Delivery)
approach to have 'Proven Architecture' ready first during the early part of the release. Many of the technical risks are related to architecture and by implementing the tricky bits early we can have the just enough Architecture ready to support both functional and non functional requirements.

Whatever I have shared above has worked for me, please let me know how do you manage Risks in an Agile project.

Feel free to leave feedback/suggestions.