We all know it, and very few solutions are available: The world is becoming increasingly Volatile, Uncertain, complex and Ambiguous (VUCA). If you are a manager, Scrum can offer you a considerable toolbox to address this problem. This is the first article in the series: Using Scrum to reduce complexity, uncertainty and risk.
Risk management has long been neglected, maybe because many Agile or Scrum practitioners see it as part of the old way of doing things. This central gap in the library of Scrum and Agile practices is one of the primary reasons why the legitimacy and usefulness of Scrum are challenged in many organizations, particularly in large enterprises or mission-critical settings.
Besides the semi-obvious advice, “Just collaborate a lot and invite everybody in,” “Just use the R.O.A.M framework (or some other tool) to classify risk,” or “Identify, Analyze, Assess, Respond and Review, etc.” there is not much practical, specific guidance available on how to address delivery risk in Scrum.
The significant issues with current Agile risk assessment and management thought are that:
We have no universal definition of “risk.”
No standardized risk management approach/formalized risk protocols exist
Risk management is not explicitly integrated into the frameworks (yet)
Focus is typically on requirements and technical risks over project risks and other risks
This post attempts to change that by showing you that the Scrum framework contains many opportunities to apply active risk management. Part of the case for moving towards Scrum (when the method is appropriate to the product context) is that Risk Management, pre-emption and mitigation are closely integrated into how Scrum Teams work.
When traditional risk management clashes with Agile and Scrum
“There is no perfect formulaic approach to assessing risk nor an effective checklist to avoid or mitigate it…While risk is often portrayed mathematically, the way we respond to risk is mostly instinctive.” These words come from the book “Risk – A User’s Guide” by US General Stanley McChrystal and Anna Butrico.
McChrystal is torpedoing the notion that we can reduce risks simply by categorizing them. Instead, he proposes a new approach to building a risk immune system that helps us cope with the fact that things might and will not go as planned.
The main message is relevant here: Conversion of risk into numbers can give a false sense of security and add to groupthink and complacency.
So, what are the other problems with the traditional Risk Management approach in an Agile setting?
Probability assessments are always intuitive but treated as a mathematical “scientistic” fact (McChrystal’s point).
It creates an illusion of control and the elimination of chance.
We typically do not know the assessment confidence level – and who has judged it.
Tight plans and hard sequentiality counterintuitively increase accumulated risk. Basically, the more complex steps a solution contains, the higher is the final probability of failure.
Extreme risk-aversion leads to paralysis and letting things happen to you instead of the reverse.
Risks drown in spreadsheets and reporting. At the bottom of the Risk Log, nobody can hear you scream.
Competing risk management setups exist in all large organizations
(finance, legal, product, project, security, reputation etc.), and some
of them er pure Compliance Theater.
Some higher-level managers can have a higher risk appetite, leading to downplaying escalated risks
Teams are not empowered to solve risks; management becomes a bottleneck.
Focus is on the probability of something happening instead of the interface by which it can be managed.
Risks are often silo-contained.
Risks are responded to but not formally incurred by somebody.
Systemic and cultural risks are self-censored, ignored or explained away.
It does not address wrongful assumptions, biases and groupthink.
Initial probability assumptions are forgotten later – it might have been 25% probable, but once the disaster strikes, it strikes 100%.
Risk and the Agile Manifesto
When looking at the Agile Manifesto, there are at least two values and five principles that can be unfolded into practical Risk Management advice:
Value: Customer collaboration over contract negotiation. Guidance: Fix problems together and avoid confrontation as the default mode. Once you are in contract interpretation territory, the fight against risk is lost.
Value: Responding to change over following a plan. Guidance: Ensure that flexibility is built into advance mandates, contracts and culture so that it does not have to be negotiated or forced through before mitigation can start.
Principle: Continuous attention to technical excellence and good design enhances agility. Guidance: Do the right thing and don’t incur technical debt.
Principle: Sustainable development: sponsors, developers, and users should be able to maintain a constant pace. Guidance: Working with stressed people increases risk.
Principle: Simplicity - the art of maximizing the amount of work not done - is essential. Guidance: Complex solutions are riskier, and much Work In Progress (WIP) increases risk levels.
Principle: The best architectures, requirements, and designs emerge from self-organizing teams. Guidance: People working on the problems know where the problems are.
Principle: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Guidance: Effective risk management involves continuous process improvement.
Risk and the Scrum framework
Two of the Scrum Values are particularly important for risk management: Courage The Scrum Team and its stakeholders dare to do the right thing and work on challenging problems.
Openness The Scrum Team and its stakeholders agree to be open about all the work and the challenges with performing the work.
As always, the Scrum Values are easy to say but hard to practice consistently—this is a management problem!
The framework itself
Traditionally, the Scrum Master facilitates team-level risk identification and mitigation. The team shares responsibility for enterprise-level risks, but many other ways exist to address risk inside the framework.
Iterative development is risk-preventing: Iterations allow fast course correction and releases, reducing business risk, and assumptions are tested early and often.
Formalized stakeholder involvement in the work of a Scrum Team is critical to reducing risk, confusion and waste.
Understand the customer's risk preference—it is probably not the same as yours—but knowing it can enable you to navigate risk more freely.
Transparency supports early risk discovery.
Create an adjustable risk profile through Agile practices:
Sprint length
Spikes and prototypes
A strong Definition of Ready
Accept criteria that reduce risk
A strong Definition of Done is a super-tool to prevent risks from happening.
Define and handle Non-Functional Requirements (NFR) early in the development value stream
Put mitigations on the Product Backlog.
Add risk as a Product Backlog prioritization parameter.
Rework over-tight, complicated sequential plans.
Reduce risk with frequent integration, testing and validation.
Use a risk burndown chart to track the risk reduction over time visually.
The formal Scrum feedback loops (Daily Scrum, Sprint Review and Sprint Retrospective) should include risk discussion to increase risk awareness.
Practice strong demo discipline – the proof is in the pudding:
Demo a lot, also to the customer – if you are afraid of that at any given time, you have more work to do before you demo!
Only demo product increments that comply with the Definition of Done.
Demonstrate fully integrated features in a state that is ready to release.
Use DevOps methods, such as simulations or blameless post-mortems.
Mitigate risks incrementally – you don’t always need to fix the entire problem.
Agile Leadership and risk
Here is some Agile Leadership advice for you. Some leadership antipatterns are specifically essential to look out for:
If you kill the messenger, you stop getting messages In a toxic, harsh or highly competitive leadership environment, the bearer of bad news, self-censors and leadership never get the complete picture before disaster sets in.
A zero-defects mentality actually increases the risk level People hide problems and are afraid to think out of the box to solve them.
Toxic leadership creates malicious compliance People do exactly what they are told, not what should be done, which hides risk. Sycophant mentality, yes-men/women overlook problems to survive.
Inconsistent decisions Forcing employees to sort out impossible or conflicting demands creates risk. Perverse incentives “What gets measured gets done” might be true, but sometimes it also means that what doesn’t get measured doesn’t get done.
Company culture and risk
You probably don’t have the culture type you think you do or the company claims (Quinn/Cameron culture type). Making this assumption can be dangerous, as it can mask actual risks, such as claiming to be an open organization when you are clearly not.
Hero culture celebrates gung-ho risk response rather than due diligence. This is a powerful narrative, but it is more expensive, and the risk is not controlled; once it appears, it can explode or spread across domains.
Low-trust cultures are inherently high-risk because micromanagement is cumbersome, destroys initiative and is almost impossible when working with knowledge workers, who know much more about the actual work than their managers. Toxic cultures are risk-prone and bad at discovering and handling risks.
Adjust your risk management method to leverage the strengths and compensate for the weaknesses in the company culture.
General advice
Practice
Active Risk Management, look for risks and constraints and improve them.
Adopt
a Shift Left/DevOps mindset - fix it now! The later in the value chain, you fix
a problem, the more complicated and expensive the fix will be. Nothing is more costly
and embarrassing than fixing a problem with a product that the customer already
has in her hands.
Fight
against technical debt every step of the way.
Estimate and add risk mitigation, process improvements and technical debt payback to the official Product Backlog and make the Product Owner or Business Owner accountable for prioritization (depending on your framework in use)
Eliminate or compensate for Process/Technical debt, Technical Debt multipliers, weak process foundations, and lack of psychological safety.
Submit the Risk Management process to relentless improvement.
Create a "boy scouting" culture – always leave things better than you found them.
Don’t let face loss, company prestige, megalomania or “think positive” get in the way of honest risk assessment.
If the customer can't handle the truth, at least ensure your management knows it.
If your management can’t handle the truth, quantify risk as cost and calculate interest rates, just like technical debt.
While this guidance is not a finely tuned and consistent framework, it leverages the principles and practices in a Scrum setting to help reduce and handle risk events.
Write your awesome label here.
Get the course now:
Scrum for managers and Stakeholders
A Roadmap to Agile Success
You’ll learn to engage with Scrum teams, improve collaboration, and build agility in your organization. The course covers Scrum fundamentals from a leadership perspective, focusing on your role in supporting product development, managing expectations, and aligning business goals with team outcomes.
Get ready to transform how you lead and collaborate. Scrum for Managers and Stakeholders is your tool to succeed in the fast-paced Agile world!
Empty space, drag to resize
Write your awesome label here.
Take a free test to find your path
Which kind of Agile Leader could you become?
Take our new test and get tailored recommendations for developing your Agile Leadership career.
The test indicates which of the three paths of Agile Leadership might suit you based on your preferences, as expressed in your choices.
Christian is an Agile practitioner, seasoned project manager, accredited Scrum & DevOps trainer and leadership consultant. He is now bringing his expertise and unique view of Agile, modern leadership and related disciplines such as Scrum and DevOps to the students at the Corporate Revolutionary Academy, which he has co-founded.
