What if some sarcastic guys would challenge us by asserting that Agile/Scrum primarily are mainly great approaches to manage risks?! Should we feel offended by that? Well, let’s see how Agile addresses and manages risks, then we can decide :o)
Once I read, don’t remember where, that Scrum is not, at all, the best approach to develop products when facing complexity; rather, it’s the best known Risk Management approach in the world.
Well, I could not agree 100% (actually, you do develop great products when strongly challenged by uncertainty) but, putting aside the sarcasm of the author, which made me smile, I found myself in sympathy with it.
If we take a look to the Agile Manifesto and the Scrum framework, there are may practices and principles which, by design, help teams to actually manage proactively risks:
- Fast feedback cycle: let you to discover in advance any bad variance between progress/value created, respect to client/user expectations. Furthermore, in case of bad surprises, you can recover pretty well and fast.
- Continuous (re)planning: Agile is based on empirical process control. This means that every iteration ends with the inspection of the product (sprint review) and the underlying process (sprint retrospective). These are key events where agile teams discover, assess any risks and adapt their behaviors according to it.
- Daily Scrum: every day the development team meet for 15 minutes in front of the board, discussing progress, plans for the new working day and impediments (risks that actually became facts) and any possible risks.
- Small batch size: Agile suggests to work in iteration. During these ones the team shall design, build, test and deploy a potentially shippable product. Iteration must be small ones (2 to 4 weeks maximum) preferring the shorter timescale when uncertainty is high. Well, this implicitly means that the amount of work is limited, more manageable, dependencies are easier to visualize, uncertainty is limited and, thus, risks are inherently less “risky” in terms of probability of occurrence and impact on project objectives.
- Team diversity and cross-functionality: teams like these ones are better equipped to explore solutions for complex problems and foreseen any possible risk in advance respect to other team typologies.
- Backlog Prioritization: backlog is prioritized by the Product Owner. There are many techniques and approaches to do that (MoSCoW, Cost of delay, WSJF, Kano, Relative Weighting); of course business value and effort (cost) are the primary factors to be considered, but also the risk is a key item that must be taken into large account when prioritizing backlog items. Why? What if we continue to deliver the most valuable backlog items (in the eye of the customer), while neglecting some very risky items that remains in the lower part of the backlog (mening low biz value) and which can derail the whole project because of tech problems or something? By the way the WSJF method from SAFe, is crystal clear on how to prioritize features and epics keeping in account risks (and opportunities as well).
If you are still reading this post, I am sure now you agree with the sarcastic guys mentioned in the introduction :o)
If we bring this one step further, by looking back on how traditional project management categorize risks, we find the following:
- Known Knowns: things that we know that we know; it regards our general knowledge. Risks we know, which we can assess in terms of impact and probability and we can decide how to manage them (owning, transferring, mitigating o accepting).
- Known Unknowns: things we know that we don’t know, or we don’t know their potential risks. They have not been accurately measured, but we are aware that in that area we could have problems or surprises and we need to monitor them accurately.
- Unknown Unknowns: these are the most dangerous kind of risks; they are strongly linked with uncertainty and complexity. We actually don’t even know, that we don’t know that they exist. Any of this kind of risks, can hit seriously and unexpectedly our project.
Agile teams intrinsically are able to address any o these categories of risks.
Daily Scrums are the primary technique they have to manage the Known Knowns.
In addition to that event, backlog refinement, sprint planning, review and retrospective, are the tools agile teams have to address Known Unknowns.
And, what about the Unknown Unknowns? Well guys, aren’t Agile and the empirical approach be made exactly for exploring uncertainty and complexity, by incessantly lowering risks through iteration execution?
