In a Conventional Project, Risk Management is the Responsibility of the Project Manager. Scope is typically limited to whether the Project comes in on Time and within Budget. There are other Risk Factors, such as Resource and Quality Management. An Agile Project does not have a Project Manager. This does not mean that there are no Risks. Risks still must be Managed as scrupulously as in a Conventional Project. Prior to examining what Risks ought to be Managed and alleviated, it is a good idea to think about Risk Management within the business in context. As the Maturity Level of the Organisation grows, how will the Risks in the Project need to be Managed.

The Organisational Path to Risk Maturity

Some Companies will have different Risk Departments and/or Initiatives, like Operational Risk and Project Risk. In these scenarios, Risk is dealt with on an ad-hoc basis. The Focus is on Risks within the Scope of that Business Unit or Project. In a Mature Organisation, Risk is managed at Enterprise Level. There could be systems for performing Risk Assessment and Mitigation within the Company. These systems are all co-ordinated and combined into a single Organisational Risk Model.

Risk Management Frameworks

As Companies become more Mature in Managing Risk, they may also embrace Frameworks to Manage Risk. Risk Management Frameworks include ISO31000, which can often be supported by a Risk Management Software App. Of course, there are still Businesses out there that depend on spreadsheets and some ad-hoc Process. However these are becoming less and less common. A Risk is everyone’s Business. Risk-Averse Companies make sure that everybody in the Company is trained in Risk Identification and the Process of Risk Management.

There may be an existing Framework for Risk Management that is used in your Organisation. You may need to use that Framework and any related Tools to report on your Project Risk. There will likewise be reporting lines to be observed. In the spirit of the Agile Manifesto, you desire to keep your Customers informed about the Risks of the Project. This is in addition to informing them of the Project Progress, thus Maintaining Transparency.

The Agile Risk Management Process

The essence of Risk Management is the Proactive Identification of Risk. The Definition of Strategies to Mitigate Risks where possible and Acceptance where risk can not be Mitigated.

Risks might be internal, that is Project Risks which are under the Control of the Team. Risks may be external, which the Team can not Control, but should Accept that they might happen. A typical internal Risk would be a Development Team member leaving the Project; a typical external Risk would be a Change in Legislation that affects the Product Development. There are lots of Frameworks around, however a generic Risk Management Process would consist of the following activities:-.

IDENTIFY – is the raising of awareness of either an internal or external Risk to the Project. Risks should be communicated to the Project Team and the Stakeholders knowledgeable about the Risk.

ASSESS – each Risk is assessed for Probability and Impact as well as how soon it may happen. A rating is typically designated to a Risk based upon this Formula:-.

Severity = Probability X Impact.

The Weightings for Probability and Impact are normally on a scale from 1-10. This may change based on the Risk Assessment Method used within your Organisation.

PRIORITISE – the Risks are Prioritised, based upon level of Severity. If you are using Scrum, you can construct a Risk Burndown Chart. This chart has much in common with a Sprint Burndown Chart.

ALLEVIATE – A Mitigation must be talked about and agreed for each Risk. Not all Risks can be Mitigated, in which case they should be Accepted.

REPORT (or COMMUNICATE) – Usually Risks are Recorded in a Risk Register. This register can be Circulated to every Project Stakeholder. The Register is updated frequently, according to the Company’s Business Rules on Risk Reporting.

We found these books great for finding out more information on Agile Scrum:

Duty for Risk Management.

In a Scrum Project, much of the Responsibility and Accountability sits with the Product Owner. The majority of the Risk revolves around successful Delivery of the Product. The Product Owner is likewise the Team member who has an active Role liaising with external Stakeholders. The Scrum Master has Responsibility for Risk too. These risks include those involving Team Dynamics and compliance with the Scrum Framework. When it comes to Risk Identification, everybody has the Responsibility to Identify Risk and notify the Team. Assessment through to Mitigation must also be a Team Effort, but this depends upon the Company’s Risk Maturity.

Incorporating Risk Management into a Scrum Project.

The Scrum Framework is designed to Reduce Risk by utilizing an Iterative Process of “Sprints” of short duration. This approach decreases Risk by giving the Opportunity to Realign the Project when it appears to be going Off the Rails. The recommended Meetings for Scrum offer an Opportunity to Integrate the Risk Management Process:-.

The Daily Stand-up Meeting – this is the ideal online forum for Risk Identification. The Risk is simply named and tabled by the Scrum Master for later Assessment and Prioritisation.

The Sprint Planning Meeting – Also a forum for Risk Identification, specifically prior to the very first Sprint. This Meeting aids Risk Mitigation by determining intricacy of User Stories. Those User Stories committed to are moved into the Sprint Backlog. Note that this does not formally form part of the Risk Management Process.

The Sprint Retrospective – A Sprint Retrospective is another forum for Risk Identification. This is based upon what took place and might be utilized to Re-prioritise the Risk Register.

The Risk Meetings – These are not part of Scrum. They will be needed to be carried out for the Assessment and Mitigation Activities. They need to be lined up with the Risk Management Framework utilized in the Company. Depending upon situations, these Meetings could be held on either a routine or an ad-hoc basis. For instance, if a Risk was raised in a Stand-up Meeting, it needs to be examined within a couple of days, due to the impact on the Velocity of the Sprints.

Acknowledging the Risks.

The Agile values and principles were developed to Minimise Risk as much as possible, through Frequent Interaction with Stakeholders, small Iterative Deliveries and the Flexibility to Accept Changes. Whatever Method you utilize, please ensure that Risk Management is a crucial Component of your Project – Agile may Mitigate a number of the Project Risks, however there are still Risks around the Product Development that need to be Managed and Mitigated.