Risk Management in Agile.

How do we assess and respond to risks?

👋 Hello, I’m Vibhor, and welcome to the 🌟 free monthly edition 🌟 of my weekly Q&A Series powered by Winning Strategy. Every week, I answer one reader question and publish 2 posts about Agile Products, Role-Based Skills, and anything else that you need answered about your Career Growth. You can send me your questions here.

---

Hi everyone,

Before I begin with the topic, I want to express my heartfelt gratitude to all of my paid subscribers. Your support means the world to me and allows me to continue creating content that I'm passionate about.

I write this newsletter not just to help Scrum Masters, Agile Coaches, and Product Owners navigate the complexities of their jobs. I write it to help them grow in their career like I did.

When I started as a Scrum Master in 2009, I was naive. I made countless mistakes. The one thing I did right at that time was writing down all my mistakes in a notebook every day at the end of the day.

Every mistake was a trigger to find an answer. It took time, but I did find the answers, and Winning Strategy is a compilation of all those answers.

I'm truly humbled by your kind words about how Winning Strategy impacts your work lives. It’s so wonderful to know that these posts resonate with you and make a difference. Here are a few testimonials that I'd like to share:

Reading your messages and feedback always brings a smile to my face and motivates me to keep going. I couldn't do this without you, and I'm so grateful for your ongoing support.

Membership Discount

As a token of appreciation, I am offering all members of my Agile community a 20% discount on a yearly subscription, available until the end of the summer vacation on August 30th, 2024. No discount code is required.

If you have any questions regarding this, feel free to send me an email at the address below:

Email: winningstrategy@vibhorchandel.com

I am looking forward to your messages.

Also, if you’re new to Winning Strategy, here’s what I published in the past few weeks:

1. Risk vs Impediment

2. Metrics for Project Based Scrum Teams

3. How to Succeed As a Release Train Engineer (RTE)?

4. Product Owner Struggling to Find Use Cases

5. First 30 Days of a Product Owner - Complete Schedule

6. Role of Scrum Master in SAFe

7. Persuasion - The Skill You Need to Lead Without Authority.

8. What to do When Asked to Provide A Date of Project Completion?

On to this week’s question!

---

Q: Hi Vibhor. We all know that agile methods have a built-in mechanism for managing risks. All this working in chunks and reflection is good, but it sometimes appears less and not enough. Why is this the case? How do we do Risk Management in Agile? Looking forward to listening to your perspective on this.

Thank you for the question.

Risk Management has 3 main components.

It is basically the process of:

1. identifying,

2. assessing, and

3. responding

to possible Risks that may affect the success of a project.

In my post last week, I talked about the 1st component of Risk Management.

I talked about:

1. what exactly is a Risk?

2. the simple difference between Risks and Impediments, and

3. how to quickly “identify” and document Risks within projects

The main focus of today’s post is the remaining 2 components of Risk Management:

1. risk assessment, and

2. risk response

But before that — do we really need dedicated Risk Management in Agile?

Let’s find out.

---

Is Risk Management Necessary in Agile?

The short answer is yes.

Many people think that because Agile emphasizes:

• adaptability,

• flexibility, and

• iterative development,

it naturally addresses and mitigates “all kinds of” risks without requiring dedicated Risk Management practices. They believe that:

• frequent iterations,

• regular feedback loops, and

• close collaboration with stakeholders

are sufficient to identify and respond to risks as they arise.

This is a myth!

Don’t get me wrong, though.

Agile does help, no doubt, in identifying and mitigating some risks early. However, it does not guarantee that “all risks” will be identified, let alone managed effectively.

For example:

Let’s say you are part of a team working on a new software feature for Amazon. Your team follows Scrum, with 2-week sprints and regular retrospectives.

Initial Sprints:

• The team successfully completes the first few sprints. It delivers incremental improvements and gathers feedback from stakeholders

• The team identifies and fixes minor issues along the way, such as bugs and slight user interface adjustments

Risk Emerges:

• Midway through the project, a significant risk emerges. Integrating a 3rd-party payment gateway is more complex than the team initially anticipated.

• This risk was not identified early because the team assumed that their previous experience with a different gateway would apply here

Impact:

• The integration issue causes delays. More time is needed to understand and resolve the complexities

• These delays cause a cascading effect, pushing back other dependent user stories. This impacts the project timeline and budget

Now, what if you had a dedicated Risk Management approach in place?

Your team would have:

1. Identified the Risk: Conducted a risk identification workshop at the beginning of the project, identifying possible Risks like the one above

2. Assessed the Risk: Evaluated the “likelihood” and “severity” of the identified Risk. Prioritized the Risk based on its potential impact on the project

and,

3. Responded to the Risk: Developed contingency plans or spikes early to explore and address such Risks

Agile methods like Scrum offer “tools.”

These tools or practices support a responsive and adaptive project environment. Here are some common examples of Risks minimized by these Agile tools:

1. Scope creep: Agile helps manage scope creep by prioritizing and delivering features incrementally

2. Misalignment with customer needs: Frequent customer feedback and collaboration guarantee that the product meets customer requirements and expectations

3. Late delivery: Iterative development allows teams to deliver working software early and often, reducing the risk of late delivery

4. Bad quality: Continuous integration, automated testing, and code reviews help maintain high code quality

5. Lack of visibility: Regular events, such as daily stand-ups and sprint reviews, keep stakeholders informed about progress and issues

6. Market Relevance: Frequent releases help test the product’s market fit

Agile methods do not replace the need for dedicated Risk Management, though. Here are some common examples of Risks that remain unaffected by Agile tools:

1. External dependencies: These include third-party vendors or integrations with third-party systems, economic downturns, new regulations, etc.

2. Budget constraints: Agile helps manage scope and prioritize features, but it doesn't control overall budget constraints

3. Legacy Systems: Outdated systems often pose challenges that Agile methods alone cannot resolve

4. Economic Downturns: Economic conditions can impact project funding and viability, regardless of Agile practices

5. Natural Disasters and Pandemics: These events can disrupt operations in ways that Agile cannot predict or prevent

6. Market Conditions: Sudden moves by competitors can change the market landscape unexpectedly

7. Legal issues: Agile doesn't address potential legal risks or disputes

So!

In summary, while Agile helps minimize many Risks associated with software products and projects, it doesn't provide a complete Risk Management solution. It's therefore important to identify, assess and respond appropriately to Risks that fall outside Agile's direct control to ensure successful project outcomes.

---

Risk Assessment

In the last post, we learned how to identify Risks. We used a scenario to document some example Risks below:

1. The team’s lack of experience in the project may lead to incorrect estimates

2. Insufficient budget may lead to scope reduction or compromised quality

3. Lack of proper training may result in suboptimal performance

4. A non Agile vendor may have rigid processes and inflexible timelines, which can cause delays

These Risks, however, are not actionable or manageable yet.

They become manageable when they are “prioritized” or described as High, Medium or Low. This is where Risk Assessment comes into play.

Risk Assessment helps your team do two things:

1. Analyze the likelihood of each individual risk

2. Prioritize risk based on its severity

How do we assess Risks?

Below are some popular techniques teams use to assess risks:

1. Risk Heat Maps

2. Decision Tree

3. Bowtie Model

4. Failure Mode and Effects Analysis

5. Risk Assessment Matrix

None of these techniques are flawless. Each has its own strengths and weaknesses. However, they are not mutually exclusive. Teams frequently combine these approaches for Risk Assessments.

The most popular and, fortunately, the simplest by far is the one that I like the most and recommend teams to use is the Risk Assessment Matrix.

Risk Assessment Matrix

The matrix assigns a risk level (e.g. High, Medium, Low) to each risk based on its likelihood and severity. Here’s how to use it:

Step 1: Identify risks:

• Use the simple technique used in the last post, or

• You can also facilitate a brainstorming session for your team to help them identify risks

• You can also use historical data by reviewing past Sprint reports, impediment logs, or any relevant project documentation

Step 2: Analyze risks:

• Likelihood: For each identified risk, discuss and agree on the probability of it occurring. Use the scale above in the matrix (1 being very unlikely, 5 being highly likely)

• Severity: Assess the potential “negative” impact of each risk if it were to occur. Again, use the matrix scale (1 being minimal impact, 5 being catastrophic impact)

• Record Findings: Document each risk, its likelihood score, and its severity

Step 3: Determine Risk Level:

• Plot each risk on the matrix or give it a colour

• Green Zone (Low): Risks in this zone might not require immediate action but should be monitored

• Yellow Zone (Medium): These risks warrant attention and may require contingency plans

• Red Zone (High): High-priority risks requiring immediate action and mitigation strategies

This concludes the Risk Assessment.

---

Risk Response

Once your team has assigned a Risk Level to each identified Risk, it’s time to work on the third and last component of Risk Management — Risk Response.

Here’s how you do it:

1. Start with the High-Risk Items: Start with risks in the red zone, followed by yellow, then green

2. For each high-priority risk, brainstorm and define specific actions to:

   • Avoid: Eliminate the risk entirely

   • Mitigate: Reduce the likelihood or impact

   • Transfer: Shift the risk to a third party (e.g. insurance)

   • Accept: Acknowledge and accept the risk if mitigation is too costly or impractical

     

3. Pick the action item that makes the most sense, given the cost and effort required to complete it

4. Assign Ownership: Clearly assign responsibility for each mitigation action to a single team member

5. Add response actions as spikes or user stories to your Sprint Backlog

Let’s go through an example with our original 4 risks:

1. The team’s lack of experience in the project may lead to incorrect estimates

2. Insufficient budget may lead to scope reduction or compromised quality

3. Lack of proper training may result in suboptimal performance

4. A non Agile vendor may have rigid processes and inflexible timelines, which can cause delays

Let’s say after the Risk Assessment, the Overall Risk Level for each of the risks above comes out to be as follows:

#1: Non-Agile vendor causes delays due to rigid processes (High Risk):

• Avoid (High Cost): Ideal but might not be possible if the vendor is already chosen

• Mitigate (High Cost): Establish clear communication channels, set realistic expectations upfront, and collaborate closely to align on timelines and deliverables. This is the most realistic approach

• Transfer (High Cost): Difficult to transfer the risk associated with a vendor's processes

• Accept (Very High Cost): Highly risky as delays can significantly impact the project

Response Strategy: Mitigate

#2: Lack of team experience leads to incorrect estimates (Medium Risk):

• Avoid (Medium Cost): Unrealistic to avoid completely as the team needs to gain experience

• Mitigate (Medium Cost): Engage experienced mentors, conduct thorough estimation sessions with multiple techniques, and break down user stories into smaller, more manageable chunks. This seems like the most suitable approach

• Transfer (High Cost): Not feasible to transfer the risk of estimation

• Accept (Medium Cost): Inaccurate estimates can significantly impact the project timeline. So, it can’t be accepted

Response Strategy: Mitigate

#3: Insufficient budget leads to scope reduction or compromised quality (Medium Risk):

• Avoid (Medium Cost): Difficult to avoid entirely, but explore options to secure additional funding or re-prioritize project scope early on

• Mitigate (Medium Cost): Implement cost control measures, prioritize essential features, and explore cost-effective solutions without compromising quality. This is a good option

• Transfer (High Cost): Not practical to transfer financial risk

• Accept (Medium Cost): Could lead to project failure or dissatisfaction if scope is severely reduced or quality suffers

Response Strategy: Mitigate

#4: Lack of proper training results in suboptimal performance (Low Risk):

• Avoid (High Cost): Provide necessary training to the team. The best course of action

• Mitigate (Low Cost): Offer on-the-job guidance and support from experienced team members

• Transfer (Medium Cost): Not applicable in this scenario

• Accept (Low Cost): Acceptable for a low-risk item, but addressing it proactively is more efficient

Response Strategy: Avoid

---

Thing to remember

Keep it simple.

In Agile, Risk Management is NOT one person’s job. It is a collaborative effort that involves the entire team.

• It focuses on proactive identification and mitigation of risks rather than extensive upfront planning

• It is an ongoing process, not a one-time activity

By integrating Risk Management into the iterative development process, Agile teams can quickly respond to emerging risks and adapt their plans accordingly.

---

This is it 🙏

If you have any questions (related to this topic), don’t forget to use the comments section to ask the community. I will try my best to get you an answer.

---

🙋🏻‍♂️ Your Questions!

If you want me to answer your questions in this newsletter, please send them my way using this link - Send me your questions.

If you find this newsletter valuable, consider sharing it with friends or subscribing if you haven’t already.

---

Till next week!

Sincerely,

Vibhor 👋

P.S. Let me know what you think! Is this useful? What could be better? I promise you won’t hurt my feelings. This is an experiment, and I need feedback. You can reply to this email to send your message directly to my inbox.

---

“I share things I wish I knew in the starting years of my career in the corporate world"

Vibhor Chandel