When exploring new ideas we often encounter new risks. This session looks at how Agile risk management needs to be lightweight, but responsive to known risks as well as previously unknown sources of risk. Building new things means encountering new things that go wrong. This session gives techniques that help identify risks early through faciltated estimation, survey crowdsourcing and historical data analysis. We then discuss how to prioritize risks based on a system impact approach and probabilistic simulation.
We do risky things all the time. Avoiding risk isn't a desirable outcome, there is value in risky ventures. We simply need to know what risks are WORTH taking. We need to take more “wise” risks than our competitors, and this session aims to define what “wise” means and how to identify them in your software development portfolio and projects.
Although risk management is thought of as boring and laborious, it need NOT BE! Agile risk management even when performed in a lightweigth fashion is key to avoiding un-intended losses - in time; in costs; in missed opportunities. If teams and organizations had a better grip on assessing their risk exposure, better decisions and fewer smashed expectation would follow.
This talk covers - Where did risk management go in Agile? Why traditional risk management doesn't work in Agile Because single point likelihood and impact estimates - we need a range based approach Because risks and delays compound and small delays propogate into large delays - we need a systems approach How to find the risks that matter most By asking the teams better risk identification questions and by using survey crowdsourcing By looking at history and measuring occurrence and impact, and forecasting future impact By using probabilistic techniques to weigh total project impact rather than isolated impact of any one risk How to quantify risk impacts and make informed risk decisions By financially quantifying things that go wrong - dollars talk By using real option and decision tree techniques to move risk decision making down to the team level
Learning Outcomes: Understand Agile risk management goals and wher current techniques often fail The problem with single point estimates of risk occurrence likelihood and impact for prioritization Training and calibrating teams on estimation, and how poor human instinct is on risk estimation without help How to elicit range estimates from teams and how to extrapolate the high end (tail risk - low probability but high impact) Learn the basics about modeling, computing and communicating risk probability and impact Learn how to put a dollar value on total risk impact through probabilistic techniques
See learning - this was excellent. Style was pretty good given nature of the subject.
Excellent presentation.
It basically showed why, for development projects, the “impact X probability”-type analysis is not really useful (issue is that if the event occurs, there is an impact on date, and we should be modeling risk associated with the release date / scope as, and if there are 2 or 3 events that come in there is a nonlinear impact on the release date), that how big something is in terms of work has limited effect of modeling risk as issues such as dependency of work and over utilization of people have far higher impact on the plan, and showed an approach to model risk more accurately using, you guessed it, Monte Carlo simulation. I've attached the presentation but, trust me, the pictures don't really help with the understanding of the main message unless you have background. Happy to talk to you about this if you want to.
Risk How well we hit an expectation or plan
How you deal with it
Plans and risk are about options
Risk - Anything that causes actual outcome to be different than planned outcome Plans of course can change
Expectation is the root of all heartache - Shakespeare
Risk About surface expectations
Two factor Penalty of being late Ability to alter outcome
Low loss, low ability to change - cost driven High loss, fixed - risk driven High loss, flexible - staff driven
Different need for risk management
Risk 1 Root cause
If working in congestion , harder to predict
How much does item size play a role in lead time Utilization is driver May work if not closer where there is at 100% utilization
Therefore - Keep utilization below a certain threshold Keep people under utilized to deliver on date Have capacity to absorb
This is number 1 risk Happy idle people
Look at system level impediments Have more impact
Trad risk management works if you have repeat work eg build house
Risk table Works for a lot of events - based on average For software projects this isn't good indicate of risk - happens once
For us date effect of risk
Zero risk 1 risk comes true and effect by delay in schedule
Leads to 4 delays means at least even chance that there is delay in projects And there are a lot of delays
Manage risk And not related to estimates As delay more related risks
Monte Carlo Probabilistic forecast
If planning on averages Fail on average if nothing else goes wrong
Average doesn't capture the big changes
See chart for risk management Get chart to Andrew
Bring the risk back means better chance of releasing earlier
This is real risk management
What are we going to solve in risk
Maximum waste is when we start work on something that is not viability Need to track ability to start Then look at things that effect multiple teams Then single teams Then stories
Need to have meeting on this
Ten failed forecasting plan assumption ( most sensitive) See questions to drive
Top 1 for your project is different based on project
Missed start date Dashboard - missed start date y/n Give duration, not date Keep history of start
Team not ready, no team Team in place. Working on something else
Partial team Forecast assumes full team If one dashboard project is delayed
Partial body staffing Skills you need Level or number
Missing skill sets
Amdahls law Speed up from parallelizing any problem will be limited by serial 8 times cost get 3 time improvement See chart Coordination cost Twice people / teams is not twice the throughput
Dependencies Best way visualize is chart Looking for number levels
Technical debt
Ship stoppers
Splitting Mistake in forecasting Original backlog versus change