Product development in a complex environment always poses some risk due to its unpredictable, uncertain nature. There are numerous types of uncertainties like business, market, technology, architecture, integration, currency, financial, marketing and hundreds more.
Facing a large number of risks while delivering products seems to be normal. And, it is. It is common and natural. What we need to do, is manage the risk.
Myth
Interestingly, more often than not, I come across the belief that risk is not a concern for Agile teams. Or, there is no need to manage risk with Scrum. Or risk is waterfall. Or, we are Agile, we do Scrum, so there is no risk.
Fact
People tend to forget about risk while working with Scrum. If not, they tend to use a mixture of traditional risk management and Scrum practices. This hybrid might not be effective and helpful. When risk is managed conventionally, and a team is working with Scrum, some people might be unaware that an adaptive way of risk management should be applied and might lose this adaptiveness. The result would be unsatisfactory. The risk would be managed from time-to-time by external people outside of the Scrum Team. Such a situation might also lead to a lack of transparency and may impact the team’s empowerment and self-organization.
Risk has no sense of belonging. Regardless of the approach you follow, Scrum, or plan-driven development, risks are always present.
And yes, as a matter of fact, we manage risk in Scrum.
How to manage risk with Scrum?
Constantly and empirically. A short answer would be to use Transparency, Inspection, and Adaption. Use empiricism. I would extend this statement to better describe the process based on my cooperation with organizations.
Together with the Scrum Team and stakeholders:
- Make a list of known risks. Discuss the probability of occurrence and impact on your product (solution, features, business, etc.).
- Categorize (whether the risk is business, currency, market or technology, architecture-related). I found this practice helpful while working with Scrum Teams. The most important part of this is a discussion that may bring value.
- Create some strategies on how to manage these risks. Is it worthwhile to pay attention to the specific threat? Or rather, can we skip it over as the probability and impact are low?
Once you made this effort, you need to refine the list frequently and adapt accordingly, otherwise you could end up with a comprehensive but obsolete list of risks. I always recommend running short sessions in a collaborative model to increase engagement, creativity and unite business and IT. It must be empirical. Frequently refine the list as often as needed. Add risk information to each Product Backlog Item complete with information about business value.
I am often asked “when to manage risk in Scrum”? Teams have a lot of Scrum Events and additional meetings. They do not think of scheduling yet another meeting to manage risk. Of course, do not do this. So, when to manage risk in Scrum?
Any time!
Scrum Events are Empirical and Support Risk Management.
Use the Scrum Events to manage risk. Many teams actually do that. Frequently unconsciously, intuitively. Just know that this effort has to be done. This is often in their team DNA. If, in your case, empirical risk management is not implemented, consider starting a conversation about risk as part of your Scrum Events.
- During the Daily Scrum the team manages risk in terms of reaching the Sprint Goal and other items that are to be delivered.
- Throughout Sprint Planning, you create a forecast, Sprint Backlog and a Sprint Goal. A forecast is all about uncertainty and, thus, risk. When creating the Sprint Backlog and sizing Product Backlog Items you are evaluating risk as part of that discussion.
- The Sprint Review is the ideal occasion to discuss business and technology risks while debating the current Increment and prospects. Such a conversation might impact your upcoming Product Backlog Items.
- Sprint Retrospectives contain fruitful conversations about what to improve as a Scrum Team which might be considered to reduce risk (process, people, technology, Definition of Done).
- The Sprint itself is in place to reduce risk through it inherent desire to create empiricism. The length of the Sprint is discussed as a risk of being disconnected from the stakeholders. Limiting the Sprint's length is often limiting risk (take into account the possibility of delivering a potentially releasable done Increment).
Scrum Activity
Product Backlog Refinement is an excellent opportunity for the Scrum Team and stakeholders to include a discussion about risk. Which item is risky yet still valuable? Which element is risky and does not bring significant value? Is it worth keeping it on the Product Backlog? What experiments do we need to run to validate our assumptions?
Scrum Artifacts are Empirical and Support Risk Management.
· Increment and release strategies are all about risk management. You might minimize the risk by delivering indeed a DONE, potentially releasable Increment and releasing it to the market. Definition of Done reflects your strategy for better dealing with the quality and the Increment “readiness to release” (done, integrated, potentially releasable).
· The Product Owner is responsible for managing the Product Backlog. One of the activities for their responsibilities is to order the Product Backlog Items through prioritization. What do they take into account? Obviously, risk and value (also size, dependencies, etc.).
· A Development Team activities include managing their risks (on how to better achieve the Sprint Goal) by revising and adjusting items in the Sprint Backlog, pointing out impediments, visualization, limiting Work in Progress, learnings from experiments, and many more.
Who should manage risk in Scrum?
The shortest and most straightforward answer is – everyone! All of the Scrum Team members are responsible for managing relevant risks.
Risk is not an impediment and can also be an opportunity!
Let’s assume you have a risky item to deliver, but also you expect considerable value after releasing it. What would you do?
I would encourage you to run an experiment(s) to validate your hypothesis. The risk might turn into an opportunity.
How to manage risk in Scrum?
- Constantly. Everyday use what you have (e.g., Scrum Events, Artifacts, Metrics).
- Have a strategy for risk mitigation, revisit this strategy frequently.
- Run short, low-cost experiments, validate your hypothesis, collect data, then make a decision. Eliminate risks early.
- Consider including risk information in your Product Backlog in the Product Backlog Items.
- Always be transparent.
- Think in terms of empiricism.
- Visualize to help with communication.
The first version of this article was published on my website: https://magdalenafirlit.com/managing-risk-with-scrum/