Agile software development is an invaluable approach when it comes to limiting compliance risk.
But as useful as ‘scrum’ it is not, and has never been, intended to be a bulletproof shield against risk.
By incorporating testing from the outset gile allows risks to be identified in the earliest stages of development and allows them to be rectified quickly and cost-effectively.
The short timeframe of each iteration, or ‘sprint’ (usually two or three weeks, never more than 30 days), allows for quick and efficient risk identification.
This does not however, negate the need for a system of risk management. So, how do you adapt your risk management strategy to the agile process?
Some wait for the risks to become issues, and then put out whatever individual fires arise as and when they break out. This reactive model, however can be seriously damaging to productivity, not to mention the potential cost implications.
The good news is that agile development can help you approach risk management proactively. Risk is an inherent part of any process, and in technological terms risk is defined as something that may cause unanticipated or unexpected outcomes.
These outcomes can be negative (issues), but they can just as easily be positive (opportunities), and both need to be addressed in a timely fashion.
While a traditional ‘waterfall’ approach to development may employ a risk register in order to manage and control risk, such a register is fundamentally impeded by the inability to see untested product until fairly late in the development process.
Agile lends itself to a simple and concise risk register in order to keep up with its inherently quick turnaround. An overly elaborate register containing excessive fields would be unwieldy in this context. A fitting template may include:
- Description of risk.
- Brief overview of risk.
- Date identified.
- Estimated likelihood of risk.
As Volkswagen found out earlier this year, it is imperative to build safeguards into your risk management practices that allow for traceability and accountability should something go wrong.
Thus it’s probably handy for your pro-forma to include;
Owner: The person in charge of responding to the risk.
Action: The predetermined response to the risk.
Status: Is the risk open, closed or being monitored.
As with any risk management the trick is to weave risk assessment into the fabric of the agile process rather than treating it as an elective add-on at the end of the process. In so doing you will hopefully notice a decreasing trend in risk with every iteration, as your sprint your way to a risk (and care) free launch!