What is Organisational Risk Management and how is it applied in Agile Projects? In a Conventional Project, Risk Management is the Responsibility of the Project Manager. It is typically limited to whether the Project is completed on Time and within Budget. There are however 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 need to be Managed as scrupulously as in a Conventional Project.

Before we analyze what Risks must be Managed and reduced in an Agile Project, it is a good idea to consider Risk Management within the enterprise in context. The Maturity Level of the Organisation determines how the Risks in the Agile Project must be Managed.

The Path to Risk Maturity

Risk Management is conducted in different ways by different Organisations. Some Companies will have different Risk Departments and/or Initiatives, like Operational Risk and Project Risk. In these situations, 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 units conducting Risk Assessment and Mitigation within the Company, however these are all co-ordinated and combined into a single Organisational Risk Model. This is due to the fact that a Risk at any level can Develop into an Issue for the whole business. For example, consider a Healthcare App that advises a Patient to take their medication. If it had a flaw that resulted in an overdose, this would trigger reputational Risk to the whole Business.

Mature Organisational Risk Management

As Companies become more Mature in Managing Risk, they might also adopt Frameworks to Manage Risk. Frameworks such as ISO31000, are typically supported by a Risk Management Software Application. Of course, there are still Businesses out there that count on spreadsheets and some ad-hoc Processes. However these are becoming less and less common. A Risk is everybody’s Business. Risk-Averse Companies guarantee that everyone in the Company is trained in Risk Identification and the Process of Organisational Risk Management.

There might be an existing Framework for Organisational Risk Management that is used in your Organisation. It is recommended to use that Framework and any associated Tools to report on your Project Risk. There will likewise be reporting lines to be observed. In the spirit of the Agile Manifesto, you want to keep your Customers notified about the Risks of the Project. This is in addition to the Project Progress, thus Maintaining Transparency.

The Agile Risk Management Process

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

Risks may be internal. That is Project Risks which are under the Control of the Scrum Team (Agile Scrum Master, Scrum Product Owner, and Scrum Development Team). They may also be external risks, which the Team can not Control. In this case they must Accept that they may occur. A typical internal Risk would be a Team member leaving the Project; a typical external Risk would be a Change in Legislation. This legislation could have an immediate impact on the Product Development. There are numerous Frameworks around, however a generic Risk Management Process would comprise the following activities:-.

IDENTIFY – is the raising of awareness of either an internal or external Risk to the Project. Anybody involved with the Project can, and should, make the remainder of the Project Team and the Stakeholders aware of the Risk.

EVALUATE – each Risk is evaluated for Probability and Impact as well as how soon it may take place. A score is typically designated to a Risk based on this Formula:-.

Intensity = Probability X Impact.

The Weightings for Probability and Impact are normally on a scale from 1-10. However this depends on the Risk Assessment Method used within your Organisation.

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

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

MITIGATE – A Mitigation must be discussed 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, which can be Circulated to every Project Stakeholder. The Register is upgraded regularly, according to the Company’s Business Rules on Risk Reporting. The format of the Register is likewise based on your Environment. If you are utilizing a Risk Burndown Chart, you can Circulate this too.

The Duty for Risk Management.

The Agile Scrum Master also has Responsibility for Risk, particularly where the Risks develop from Team Dynamics and compliance with the Scrum Framework. When it comes to Risk Identification, everybody has the Responsibility to Identify Risk and inform the Team.

Incorporating Risk Management into a Scrum Project.

The Scrum Framework is designed to Reduce Risk by utilizing an Iterative Process of “Sprints” of short period, rather than a monolithic Development Lifecycle. This approach lowers Risk by offering 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. The ideal forum for Risk Identification. The Risk is merely named and tabled by the Scrum Master for later Assessment and Prioritisation, because of the short time-frame set aside to the Stand-up.

The Sprint Planning Meeting. Also a forum for Risk Identification, particularly prior to the first Sprint. The Sprint Planning Meeting aids a lot in Risk Mitigation by determining complexity of User Stories, although this does not formally form part of the Risk Management Process.

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

The Sprint Review and Retrospective. These meetings are another forum for Risk Identification, based upon what happened and might be used to Re-prioritise the Risk Register.

The Risk Meetings – These are not part of Scrum, however will be needed to perform the Assessment and Mitigation Activities. They need to be aligned with the Risk Management Framework used in the Company. Depending on the situation, these Meetings might be held on either a regular or an ad-hoc basis, for instance, if a Risk was raised in a Stand-up Meeting, it should be examined shortly after the meeting.

Acknowledging the Risks.

While 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, the Risks intrinsic in any Project still exist in Agile. Whatever Method you use, please ensure that Risk Management is a vital Component of your Project – Agile may Mitigate many of the Project Risks, but there are still Risks around the Product Development that are required to be Managed and Mitigated.