Risk Management in Agile vs Predictive delivery models
You must have noticed that scrum do not provide any direction or inputs on the process of risk management. It must be understood that risk management is intrinsic to any project and risk management follows its own life cycle to exploit opportunities and manage the threats.
Risk management is integral part of the project management
and irrespective of a delivery framework or methodology it needs to be managed
and looked at proactively.
During predictive model of development, we typically perform
Risk Management weekly and considerable amount of time is spent on the process
to identify the unknown risks. I’ve experience of spending minimum of 3 to 4
hours every week on risk management along with the team itself and whole team
hated performing this activity as it never provides direct value to teams. In
predictive model, project manager’s stakes are higher than team and this team
has lower or no motivation to have a risk management meeting.
In my experience at any point of time we had 50+ item on our
risk tracker and team performs analysis, identify response plans for each one
of them every week.
In that risk register some items were present and no one had
a clue on what they are only date of mitigation changes. Did you have any such
items on risk tracker?
Risk Management in Predictive delivery model
PMBOK Six step process
PMI suggests The Six-Step Process of Project Risk
Management as depicted in below diagram, please refer PMI
website for more details.
Generally large programs maintain risk register with a weekly
cadence and capture various attributes of risk, below is a typical format to
capture risk and monitor them at a cadence. For more details please do refer PMBOK® Risk
Management Process.
There is various risk management template but following is
the most common way of capturing information.
https://docs.google.com/spreadsheets/d/1IZP_XXlpt3BZdQuwGkvvhxl-1GqXvTaOKLon2wpX1xY/edit?usp=sharing
Risk Management in Scrum
Fact
Like I said in above paragraph, Risk is always associated with
things we do, and they need to be managed irrespective of delivery approach.
Get shredded with Risk log
Scum is founded on empiricism and lean thinking and we need
to change the mindset of performing risk management, we need to be light and
easy unlike risk management process followed in predictive delivery models.
Some of the key characteristics of scrum help us shred that THICK risk management log
- The entire Scrum Team is accountable for creating a valuable
- The Scrum Team is responsible for all product-related activities
- The Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint.
- Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint.
The use of lean principles will also support in shredding the risk log, I’ll suggest to follow the 6S Lean principle which is Sort, Set in Order, Shine, Standardize, Sustain and Sort to get a slim risk inventory.
Cancel the explicit risk response meeting
Teams are working hard and focused on delivering sprint goal
via navigating with various scrum
ceremonies and events, I must say “they are busy”, and we do not
need to have any other formal meeting during the sprint to address risk responses.
A risk meeting within the sprint will make you move towards traditional model
of development.
Identify, Capture, and derive risk response with-in the scrum framework.
Not scrum master, not product owner but let teams own the risks
In a predictive delivery model, project managers were responsible and accountable for project delivery, they drives the risk management meetings but as we move towards scrum, self-organizing teams are empowered and take responsibility of risk register or risk mitigation plan.
Scrum Ceremonies and Risk Management
In following few paragraphs, we shall review the support of
risk management in scum events and ceremonies.
1. Daily scrum
Each day team focuses on delivering sprint goal. This is one of the first spot to monitor risk, identify risk and create a response strategy to manage risk related to sprint goal
2. Sprint Planning
While team is answering following three topics in sprint planning, team will come across various risk which needs to be logged and need to be monitored as part of daily scrum.
- Topic One: Why is this Sprint valuable?
- Topic Two: What can be Done this Sprint?
- Topic Three: How will the chosen work get done?
The above topics will enable team to freeze the sprint goal, support conversations to understand impediments and risks before the event concludes.
3. Sprint Review
This event is a working session and ideally must avoid any presentations. Team demonstrate the outcomes and highlights the risk, issues, and any impediments towards the product goal. These risks could be business or technology. Together along with key stakeholder’s team identify the response strategy to mitigate risk or identify a resolution/workaround for the impediment.
4. Sprint Retrospective.
The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness. The team engages in the conversation and looks back to identify the areas of improvement and things team may continue to increase productivity and outcome of sprints. The responses and outcomes are added to product backlog and team adopts to the outcome.
Scrum manages risk more efficiently, because of the three Pillars of Empiricism and its underlying agile principles which focuses on Individual and Interactions, working software, customer collaboration and responding to change.
