PM Tech Corner: Risk Management—Agile vs. Waterfall

Welcome to the Technical Corner for PMI Portland chapter.  This news article section is designed to help Project to Portfolio managers leverage tools, technologies and best practices in delivering stellar value in your daily work activities.

My name is Tim Runcie and I have spent the last 20+ years working with both technologies and methodologies supporting Project, Program and Portfolio managers globally.  You can say it is a passion at our company Advisicon, helping our customers and community or practice practitioners achieve better ROI with the blend of both tools and technologies.

As a Gold PPM partner with Microsoft, I welcome hearing requests and feature add requests for improvements on Microsoft tools, so feel free to communicate those with myself my team any time! 

I personally hope you enjoy this and want to encourage people to reach out directly to me for follow up, questions around this and any other technology and methodology topic.  I can always be reached at Tim.Runcie@Advisicon.com

In this month’s article, working in the technology sector, I constantly am presented with opportunities to leverage different methodologies and approaches to delivering projects.  One of the most common questions that comes up is the Agile vs. Waterfall, or Agile vs. Prince2, or combinations of Agile vs. a different methodology.

Since the PMI standard lifecycle is most commonly referred to as Waterfall, I wanted to help answer the many questions I receive around what/how is the risk management approach in Agile different than Risk Management in Traditional Waterfall Methodology.  This may seem like a simple question, but I have seen where both methodologies, in the same circumstances, deliver very successfully.  I have also seen where both methodologies have failed in their delivery of the Project Goals.

In most cases one of the common areas that people struggled with, is how they managed Risks.

This month’s article will be to highlight and compare for you, the Risk Management approach in Agile vs. the standard Waterfall method of Risk management.

Risk Management Approach Differences in Agile vs. Waterfall

Now for this article, I didn’t want to go into every detail around risk management, nor discuss all the moving parts of Risk Management.  What I did want to highlight was on where and what the differences are between the two methodologies.

It is very important to not treat the risk management approach of Agile the same way as you do Waterfall.  I have seen many technical project managers who bring in their traditional approaches around risk management only to find that they really they weren’t adequate enough.

Let me illustrate this with a short story.  In my early career, I was part of a Construction battalion (Seabee’s) with the US Navy.  The construction branch is a separate branch from the standard Navy, just like the Marines are a different branch of the US Navy.  Part of our role was to not only build, construct and manage public work projects, but also to have a dual functionality, an additional combat role.  It was in this combat training that we were trained on how to transition from doing construction work to rapidly shift into a combat role and assume combat duties.  This was critical to the success and survival of getting work done, but also being able to quickly transform into an effective combat unit.

One of the training techniques was to actually be part of the target team down range of live fire, running up targets for those who were practicing.  Sometimes our combat instructors would fire off live rounds as we trained.  Let me tell you there is nothing like whizzing or pinging rounds of live ammunition, seeing tracers flash overhead to make you move faster and get sense of how important it is to respond more quickly or in an agile way from doing one job to shifting to another.

To this day I love to play paintball, which simulates much of the same experience you have in a live combat exercise (minus the dying part).  When playing paintball, the whizzing or splat of a paintball over your head, by you will make your reflexes increase instantly, or you will feel the welt and sting of not moving faster.

Risk management in Agile takes on a more active and reactive role which is important to factor into daily activities.  Waterfall typically you have more time to plan or you have longer projects or more stable environments, where requirements don’t change that often.  In traditional project management, your approach to Risk management is important, but it is not as active or ever present as you find in an agile environment.

Let’s take a look at these as well as some tools that will help you in either scenario for Project Management.

Key Successes & Failures with Risk Management in Agile vs. Waterfall

What I love about doing project management is that there are detailed and robust processes around it.  This is true for Agile as it is for Waterfall.  Since both approaches leverage an Identify, Quantify, Prioritize, Plan and Manage approach, on the surface they appear to be very similar.  It is in the frequency of the risk process as well as the management layer where we see the key differences.

In waterfall, we do more up front planning, including risks, whereas in Agile (being inherently iterative), risk management goes through a more cyclical and repeated risk planning exercise.

Let’s go through the cycle of risk management and some of the approaches and tools that support great risk management.

Remember we plan for risk we know about as well as one’s we don’t know about.  The more iterative approach for Agile, allows for these unknowns to be surfaced and addressed on a daily basis (especially if you are using Scrum), where in a more traditional approach, only the largest risks are usually identified and planned around.  In traditional projects, risks tend to be more predictable (not to say that they don’t dynamically appear), but it is the technical projects that tend to have more unknowns, and so the need for more dynamic risk management.

A common approach is to list risks and use a type of Probability and Impact statement or matrix to quantify these.

Here is an example of a Risk Identification Matrix.

We also see risks listed in Tiers’, including top ten 2nd tier, etc. to organize them.  The overall idea is that you have working sessions to identify risks that need to be evaluated and/or managed.  It is important to surface as many credible risks and then evaluate which risks you need to address, versus spending time on risks that may not occur or if they do have little to no impact.

Remember also that Risks can be good.

Typically, in technical projects, a risk can be defined as simply “uncertainty that matters”. This leads to the fact that risks can also have a positive effect.  In projects, uncertainty isn’t necessarily negative.  It can mean opportunities for your team and as a consequence, risks actually can have a positive impact your project.  That’s why in risk planning, especially in iterations, or multiple designs, when building or creating a solution that hasn’t been built before sometimes taking healthy risk is something you actually plan for.  Knowing when and at what threshold to plan for risk uncertainty or attempts is how your team will mitigate negative risks (threats) and exploit positive risks (opportunities) as they work in the development lifecycle.

Those of you who have led or been involved in a SWOT Analysis (Strengths, Weaknesses, Opportunities, and Threats) session may have some experience in identifying these.  The same holds true in risk planning and especially in agile projects.

For key successes or failures, that are common in this industry, is the fact that when doing agile project management, that ignoring the need to constantly do risk planning, analysis and adjustments to the team work tasks has led to failed projects or being unable to deliver all the features or capabilities desired by the project.

Agile teams traditionally do not use any kind of intentional risk management approach as the very nature of the agile project tends to help address risk and communications.  But don’t let the nature of agile projects be the cause for not doing risk management.  Failure to infuse risk management into the daily or sprint cycles is a huge win for ensuring success or to help a team to stop spinning their wheels and focus on higher priority features. I personally have found that ignoring risk is a huge missed opportunity and tends to increase project costs by the team having to learn through failure.

Risk Quantification & Prioritization

Once the process and the risk identification is completed, then best practices move to risk ranking or the quantification of the risk identified.  Commonly in both Agile and Waterfall risk identification, are that you look for key information that will help you rate, rank and prioritize those as you are identifying them.

Some of these factors are:

• Size of Risk Impact (Cost, Schedule, Work, Political, Visibility)
• Advanced Warning
• What Type of Risk it is (Customer, Cost, Schedule, Scope, Training, etc.)
• Likelihood of Occurrence
• Frequency of Risk Occurring

So after listing and detailing all risks in the risk registry, it is extremely helpful to build or use a risk matrix by assigning values to each identified risk.  In the example above, we use 3 dimensions, the probability (likelihood and vertical axis) and impact (severity & size of the bubble) and the advanced notice (horizontal axis).

In Agile risk management, this matrix and risk register are reviewed (if you are using Scrum, daily), or in other agile approaches done at the beginning and end of each sprint cycle.  Sprints are a set number of days or weeks that work is done (allowing tasks to be time boxed).  A key way to think about risk management differences between these two methodologies is in how the risk steps are implemented as well as when they are implemented. Risk management in a Waterfall project is a planned step of your project lifecycle.  With Agile, it happens in a more integrated way as well in each iteration that a project goes through.

In this example, you can see that each sprint (regardless of how long it is), or each release cycle is like going through mini planning, execution and closeout cycles.

With Agile, it is important to leverage risk planning early and often, typically validating the risks, surfacing the risks and requantifying the risks at each stage of the sprint.

I have heard from many PMs who are stepping from waterfall methodology to agile approaches, say that they have a hard time finding information on risk approaches.  One thing to remember is that in agile projects, risks are often not referred to as “Risks”, but as “Impediments”.  Subtle, but slightly different in tools and reference information available.

Risk Comparison Summary and Additional Risk Tools

So as we look at the cyclical nature of risk management for Agile or even the core risk planning around Waterfall, we find that many of the elements and toolsets are the same.

However, a key difference in agile projects is that risks identified can be more technical in nature.

What that means is that the goal of a sprint it to produce features and functionality.  That means working code with tangible and visible results to customers.

In doing technical projects sometimes the risks surface and become issues that need to be either addressed or prioritized or in some cases identified, but not addressed.

In this process of doing a retrospective, using a Risk Root Cause Analysis is extremely helpful in enabling technical teams to identify key leading causes and then prioritize for future releases or sprints the elimination of these causes or issues in a planned and controlled manner.

Below is an example of a root cause analysis tool that is commonly used to help prioritize risk causes that lead to overall failures.  Instead of trying to solve all possibilities, you can break these root cause suppositions down and begin eliminating them to help eliminate risk or potential risk factors.

Remember, helping your team’s focus, prioritize and not be distracted is part of the role of the Scrum Master, Project Manager, Feature Owner and the whole managing delivery team.

I've found that there are some key things to keep in mind when incorporating risk management practices with agile teams:

• Use the Short or Small Team Risk Evaluation workshops instead of the large planning session.  These shorter sessions helps to not only begin to ingrain risk planning and thinking in the team, but it also takes less time and helps to avoid time spent on risk analysis that may not occur once you start an iterative process.
• Always keep the risk register visible and available to everyone.  SharePoint, Office 365 or using Wikis is an excellent approach.  Just centralize the information and make that collaboration portal (whatever it is) available to the wider team and stakeholders.
• Working with agile teams is a very dynamic process and in many cases they are self-organized and very democratic. At Advisicon, we like to establish a role for one of the team as the “Risk Manager.”  Their responsibility is to help identify and to help prioritize and escalate risk steps, mitigation and contingency plans with the team and stakeholders
• Don’t overthink risk ranking.  In many cases doing a team vote, or using an electronic tool to help simply weigh and rate them can help to eliminate the loudest voices in the room and to help engage the team in the analysis vs. championing their favorite risk.

In summary, regardless of the specifics of your projects and whether you are using a Waterfall or Agile method, your team is sure to face some unforeseen or less expected issues during development. Preparing for these risks is essential in ensuring your project’s success and avoiding overhead.

I hope this was helpful for you and that you enjoyed this Month’s article on Risk Management Differences between Agile and Waterfall.

You can find more on our YouTube Channel covering PM tools, methodologies and best practices at https://www.youtube.com/channel/UCzcAEnYWfm14KhSv4Y6H3bA,  or check out our live webinars on Wednesday (called Webinar Wednesday at www.Advisicon.com/webinars), where on Wednesdays we are presenting training, free PDU’s on technology supporting Project, Program and Portfolio management.

If you want to share a template or like some of the ones I showed, send me an e-mail.  I would be happy to share an example file with you.

Again, our goal for the PMI Tech Corner is to supercharge your ability in to produce results with tools, processes or a combination of both for optimization of your project management experience.

Warmest wishes for your work and do reach out to me at Tim.Runcie@Advisicon.com for questions or other techniques/tools and blended methodology approaches.  Happy PM’ing!

About the Author

Tim Runcie is the president of Advisicon (a Gold PPM Company), a 20+ year project, program and portfolio expert and member of the Microsoft Advisory council.  Tim is also the author of over 36 books on technology and project management and a 12+ year nominated and awarded MVP at Microsoft. Tim and Advisicon offer webinars, classes and customized training for all your project management needs.