π 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:
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:
identifying,
assessing, and
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:
what exactly is a Risk?
the simple difference between Risks and Impediments, and
how to quickly βidentifyβ and document Risks within projects
The main focus of todayβs post is the remaining 2 components of Risk Management:
risk assessment, and
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:
Scope creep: Agile helps manage scope creep by prioritizing and delivering features incrementally
Misalignment with customer needs: Frequent customer feedback and collaboration guarantee that the product meets customer requirements and expectations
Late delivery: Iterative development allows teams to deliver working software early and often, reducing the risk of late delivery
Bad quality: Continuous integration, automated testing, and code reviews help maintain high code quality
Lack of visibility: Regular events, such as daily stand-ups and sprint reviews, keep stakeholders informed about progress and issues
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:
External dependencies: These include third-party vendors or integrations with third-party systems, economic downturns, new regulations, etc.
Budget constraints: Agile helps manage scope and prioritize features, but it doesn't control overall budget constraints
Legacy Systems: Outdated systems often pose challenges that Agile methods alone cannot resolve
Economic Downturns: Economic conditions can impact project funding and viability, regardless of Agile practices
Natural Disasters and Pandemics: These events can disrupt operations in ways that Agile cannot predict or prevent
Market Conditions: Sudden moves by competitors can change the market landscape unexpectedly
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:
The teamβs lack of experience in the project may lead to incorrect estimates
Insufficient budget may lead to scope reduction or compromised quality
Lack of proper training may result in suboptimal performance
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:
Analyze the likelihood of each individual risk
Prioritize risk based on its severity
How do we assess Risks?
Below are some popular techniques teams use to assess risks:
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.
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:
Start with the High-Risk Items: Start with risks in the red zone, followed by yellow, then green
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
Pick the action item that makes the most sense, given the cost and effort required to complete it
Assign Ownership: Clearly assign responsibility for each mitigation action to a single team member
Add response actions as spikes or user stories to your Sprint Backlog
Letβs go through an example with our original 4 risks:
The teamβs lack of experience in the project may lead to incorrect estimates
Insufficient budget may lead to scope reduction or compromised quality
Lack of proper training may result in suboptimal performance
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
Hi @Vibhor. I loved this article, its comprehensive. Just one question. In the risk response section, you have put High or Medium Cost for each of the responses. How do you derive this scientifically (cost & effort), please elaborate or is it a gut feeling based on past experience? Thanks Krishna