Agile Project Risk Management – How does it work?
In my experience as a Project Manager, typically for traditional/Waterfall projects, the project team is expected to manage risk using a Risk Register, as well as techniques such as Probability & Impact Matrix. For larger projects (or programs), an organization may also apply techniques such as a Risk Reserve (also known as “Management Reserve” or “Risk Buffer”) which could consist of budget and/or schedule to account for unexpected activities.
For a project that follows Agile practices, the risk management process is much less formal and has less structure in most situations. One reason for this is that Agile Project Management does not have a formal doctrine such as the PMBOK (Project Management Book Of Knowledge) that offers specific guidance on how to manage risk. Some critics of the Agile approach state that the lack of formal risk management is a shortcoming since risks are not managed in a structured fashion. The thinking behind this is that an Agile project can often be executed in a very chaotic and seemingly disorganized way.
Despite the lack of formal guidance, risk management is still very important on Agile projects. There are many techniques that can be applied to Agile projects that improve your probability of success. I will share a few of these based on real-world experience.
In the world of Agile projects, risks are often managed in a subtle way that is more difficult to observe. Let’s first clarify what types of risks exist within an Agile project. Generally, although most Agile projects do not have a fixed scope, risk of scope creep is still very much present and must be managed. Schedule risk is not as big of a deal since Agile projects tend to not have fixed milestones. Cost risk is typically not an important element assuming the team is operating with stable resources including fixed expense profile. Quality, on the other hand, is tied directly to scope, and is one of the more important risk factors to consider for an Agile project. During execution of an Agile project, most of the time, risks will be identified, discussed, and managed somewhat organically through each of the team collaboration events.
Looking at this from the perspective of a Scrum team, when teams meet daily in the Daily Scrum/Daily Standup, risks are identified when team members share their progress on current tasks. If specific tasks are taking longer than originally expected, a risk is revealed and the team should respond to the risk through some type of action; the team may decide to employ any number of response plans, such as: (1) Accept the risk by doing nothing, (2) Mitigate the risk by resolving the issue, (3) Avoiding the risk by changing the plan, or another approach. Usually, this type of execution risk falls into the scope, schedule and/or quality; if a unit of work takes longer to complete, the overall Release schedule may be at risk due to the quality/capability being uncertain.
In other team-level events, such as Sprint Planning, the team actively manages risk by discussing what work items they will commit to for the specific sprint; instead of being told what to do and how to do it, and assigned individual tasks, the team works together to come up with a plan of attack to deliver the highest possible value based on their understanding of the business need and constraints. This is essentially a risk mitigation exercise.
Within the Sprint Review, the team examines completed work against original plan to determine what work was unable to be finished for the sprint. Identification of current state is a risk management technique to assess status of the project, which enables the team to take corrective action or make adjustments as needed. Hence, the Sprint Review can also be considered another risk management approach.
One of the most critical components within the Scrum practices is the Sprint Retrospective, which is an event that enables the team to reflect on successes and challenges so that they can make adjustments that will hopefully improve their performance in the near future. Discussing and committing to changes in the process allows the team to reduce the chances of encountering the same problems, hence increasing the probability of success. In essence, this process allows the team to reduce the risk of issues caused by people, process, and/or tools.
In closing, it is my hope that this short article helps to demystify some of the misconceptions related to Agile project risk management. In practice, essentially all of the primary practices within an Agile/Scrum project are designed with the intent to help teams manage risk in different ways. Skillful application of these practices will empower teams to manage risks proactively and effectively, which will optimize the chances for project success.