Product development in a complex environment always poses some risks due to their 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 a standard. And it is. It is common and natural. All we need to do is to manage 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. Risky requirements? Risky business strategy? Risky technology?
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.
Fact
Risk has no sense of belonging. Regardless of the approach you follow, Scrum, or plan-driven development, risks are present all over.
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 describe better the process based on my cooperation with organizations.
Together with the Scrum Team and stakeholders, make a list of existing risks, those you are aware of. 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 would 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 consolidate business and IT. It must be empirical. Refine the list as often as needed but frequently. Add risk information to each Product Backlog Item. Complete with information about business value.
I get asked quite often 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 them to manage risk. Plenty of teams actually do that. Frequently unconsciously, intuitively. Just know that this effort has to be done. This is in their DNA.
If, in your case, empirical risk management is not implemented, consider starting a conversation about risk while having your Scrum events.
Daily Scrum. This event contains managing risk in terms of reaching the Sprint Goal and other items that are to be delivered.
Sprint Planning. While having a Sprint Planning, you create a forecast, Sprint Backlog and a Sprint Goal. A forecast is all about uncertainty and, thus, risk.
Sprint Review. This event 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 Retrospective. A fruitful conversation about what to improve as a Scrum Team might be considered to reduce risk (process, people, technology, Definition of Done).
Sprint itself. 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. This 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 to keep it in 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 also all about risk management. You might minimize the risk by delivering indeed 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).
Product Backlog. The Product Owner is responsible for managing the Product Backlog. One of the activities for this person is to order the Product Backlog Items. What do they take into account? Obviously, risk and value (also size, dependencies, etc.).
Sprint Backlog. 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. Depending on the role in a Scrum Team.
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 a 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. Every day use what you have (e.g., Scrum Events, Artifacts, Metrics).
- Have the current strategy for risks 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.
- Employ Transparency daily.
- Think in terms of empiricism.
- Visualize.
