5 Ways Agile Risk Management is Different

“When written in Chinese, the word ‘crisis’ is composed of two characters. One represents danger and the other represents opportunity.”
– John F. Kennedy

Reality is messy.

It’s even messier when reality doesn’t stand still. Reality is complex if not chaotic at times.
One of my favourite descriptions of ‘complexity’ is from Dave Snowden. He was asked to describe his Cynefin complexity theory in 7 words or less. His answer?

“A children’s birthday party – that’s complexity.”

Just when you think you’ve figured things out in the ball point game of life, an extra ball tossed at you or a rule change randomly introduced lowers your score. You wonder, “Is there any way I could’ve prepared for those events ahead of time?”

Which brings me to the topic of Risk Management. It’s a topic I’ve always been curious about ever since I encountered my first risk register replete with a top 10 list of colour-coded risks. Each risk fully specified with risk exposure metrics and trigger-ready italicized risk response plans. It was a poster-quality work of art. The epitome of predict and control ways of working. However, what worked then in yesterday’s reality would fail miserably in today’s reality.

And yet the topic of risk management remains top of mind with many organizations today. Especially those moving to Agile ways of working. Self-organizing teams, faster time-to-market and happy customers? Great, but how are we managing and reducing risks?

A couple of recent events inspired me to reflect again on risk management.

One organization I’m working with identified a prioritized list of business outcomes they felt were most positively influenced by Agile. “De-risked Delivery” made the top 5 business outcomes.
Another organization sought my advice in creating a project risk management framework.

I’ve experienced and observed three approaches to risk management. I’m not suggesting one is better than the other. The effectiveness of each will depend on the circumstances. My objective is to highlight the differences.

Old School Risk Management

PMI’s Project Management Book Of Knowledge, affectionately referred to as “PMBOK” specifies 10 PMBOK knowledge areas. Risk Management is one of the 10 PMBOK knowledge areas. PMBOK’s Risk Management approach in the 6th edition consists of 7 processes:

Risk Management Planning
Risk Identification
Qualitative Risk Analysis
Quantitative Risk Analysis
Risk Response Planning
Implementing Risk Responses
Risk Monitoring and Control

The following picture details out each of the processes.

Middle School Risk Management

I have a hypothesis: Every organization moving from PMBOK ways of working to Agile ways of working will pass through the halls of this school.

For organizations here, there are 2 paths they can follow vis-à-vis risk management.

Continue espousing PMBOK prescribed risk management processes ‘as-is’.
Start looking at PMBOK through an Agile lens

I’m not aware of any organizations moving to Agile who have taken the first path. Even the Project Management Institute (PMI) itself has taken the second path. PMI recognized the need to consider Agile by introducing information about Agile in its latest 6th edition of the PMBOK.

The second path is not an easy one. Especially for those organizations using both PMBOK and Agile ways of working, I empathize with those enlightened PMOs that try to bridge the divide between the 2 ways of working. Challenges range from use of words like ‘assign’ as in “Each risk must be assigned to an owner…” to the type and amount of risk documentation required.

One person that I feel has done a lot to bridge this divide is Jim Highsmith. As one of the Agile Manifesto signatories, he clearly understood Agile. At the same time, his book “Agile Project Management” and his driving influence behind the 2005 “Declaration of Interdependence” (DOI) for project leaders demonstrated his desires to forge this second path. On the subject of risk management, one of the six DOI principles states,

“We expect uncertainty and manage for it through iterations, anticipation, and adaptation.”

In his book, he notes,

“The best bang-per-buck risk mitigation strategy we know is incremental delivery.”

New School Risk Management

Here, risk is accepted as an everyday occurrence. As common as the air we breathe. The focus is on nurturing, growing and sustaining adaptability and resiliency. In effect, becoming what Nicolas Taleb coined “anti-fragile”. What could new school risk management look like? Here’s what I think:

As many of you know, the PDCA cycle is not new. It predates the 1st edition of PMBOK by over 50 years if you consider its PDSA predecessor. Another blast from the past example of what’s old is new again.
Here’s a personal story to further illustrate.
I have 3 children. Five years separates the youngest from the oldest. When my wife and I were raising them, first-time parents would seek our advice on the do’s and don’ts of parenthood. For some reason they thought that since we survived parenthood 3 times, we would have some sage advice to share. I’m not sure about sage advice but we would tell the following story.

With our first child, we hovered over him every waking moment. We didn’t allow him to pick up anything outside for fear of being exposed to germs.

With our second child, we hovered less. She and her brother did a great job of dividing and conquering our attention. We allowed her to pick up things that looked safe like leaves, branches and stones.

By the time our third child came along, we didn’t care what she picked up as long as it didn’t have sh*t on it!

The risk of exposure to germs didn’t change from one child to another. So, what changed? It was our attitude that changed. Our perception and tolerance of the risk changed. Changes that came about over the course of many PDCA learning cycles and birthday parties with each child. Rather than avoid the risk outright, we learned to accept that a little exposure to germs might actually be good for them.

New School vs. Old School

Let’s imagine that Agile ways of working are representative of new school risk
management. How would Agile inspired risk management differ from PMBOK inspired risk management? Here are 5 differences that I see between Agile risk management and PMBOK risk management.

#1: Reactive vs. Proactive

PMBOK risk management advocates for a proactive approach to planning for risk. Its focus is on planning for, identifying and managing risks as early as possible. A predominantly predict and control approach.
Agile risk management prefers to react and adapt to risks when they are realized. Decisions and any associated work are often delayed to the last responsible moment. Not because of procrastination but rather to minimize waste. A predominantly sense and respond approach.

#2: Acceptance vs. Avoidance

One could argue that once a risk is realized or accepted, it’s no longer a risk but an active issue. Agile ways are very good at welcoming and adapting to change for the benefit of the customer. So, would it be too far of a reach to suggest the same for risks? Risks aren’t always negative. Realizing a risk can have positive implications. So, a realized risk won’t always become an issue. It could become an opportunity for the customer. The Agile Manifesto goes further to suggest that it could become a customer’s competitive advantage. Agile ways encourage people to run fail-fast and fail-safe experiments. Think of each Scrum sprint as a mini “cone of uncertainty”. At the end of each sprint, you’ll know more after experimenting and experiencing with work and risks alike.
My experience with PMBOK risk management always left me associating risk with predominantly negative connotations. Risk was something to be avoided, transferred or mitigated. Accepted only as a last resort. I wonder how many positive customer opportunities may have been lost due to this type of thinking?

#3: Collective Ownership vs. Helicopters

Agile ways promote shared responsibility and collective ownership amongst team members for everything the team creates and delivers. This extends to risk management. As with any other work item, risks and related risk response tasks are free to be pulled by anyone on the team who has the desire and/or competency and/or capacity to do so. The PMBOK risk management process is typically owned by a project manager or a line manager. Any activities or tasks arising out of the process are assigned to resources to ensure ownership and accountability. The project manager or line manager will then follow-up regularly with assignees to ensure progress is being made. Just like helicopter parents (I was one of them with my first child), helicopter managers feel they are doing what’s best for all concerned.

#4: Continuous vs. Episodic

Agile risk management is an everyday affair. It’s part of the fabric of Agile life. It’s no different from the continuous planning that happens with Agile ways. Risk management is continuous as well. I’ll use the Scrum events to illustrate:

The Sprint event itself is a regularly scheduled and time-boxed container for the inspection and adaptation that underpins the PDCA cycle.
The Sprint Planning event provides for deeper discussions between the Product Owner, stakeholders and all team members on the details of each sprint backlog item. Including identification, analysis and potential response plans for any risks identified.
The Daily Scrum event is an opportunity to identify potential risks simply by answering the question “Do I have any impediments or blockers affecting me?”
The Sprint Review event provides an opportunity to highlight learnings from the sprint including the discovery of any risks. The demo of sprint deliverables also provides a forum to openly highlight any potential risks, their impact and decide on response to the risk.
The Sprint Retrospective event is an opportunity for the Scrum team to reflect on learnings and decide on what improvements to action in the next sprint. These improvements could include implementing risk response plans.

PMBOK risk management by comparison is more episodic in nature. Risk meetings called my management may be regular in nature as well. However, in my experience they are far less frequent than daily with perhaps the exception of mission-critical risks.

#5: Interactions over Processes

This last difference reflects the power of value #1 in the Agile Manifesto. Value #1 prefers individuals and interactions over processes and tools. I’ll use an example to illustrate.

I was a visitor at a daily Scrum of Scrums recently. At one point during the scrum, one of the people leaders raised the risk that the Release Manager, George was going on vacation shortly. He offered up a suggestion that perhaps the team should start involving Jill who was going to be George’s backfill in all their deployment activities so she could ramp up. All the team members nodded their acknowledgement and commitment to do so. And that was it. No risk register needed to be updated. Ownership was taken as soon as the people leader finished the last word of his last sentence. No lag time.

The funny thing is, they never once used the word “risk” during the conversation. It was just part of their everyday world.

[Note: The JFK quote at the beginning of this post describing his interpretation of the Chinese characters for the word crisis has recently been shown to be incorrect. The second character does not translate to “Opportunity” but rather something close. Specifically, based on a 2014 article, the second character translates to “incipient moment; crucial point (when something begins or changes)”. Nevertheless, I love JFK’s intent with that quote]