Agile Risk Management

© 2014 Scrum WithStyle scrumwithstyle.com
Agile Management
With Rowan Bunning,
Agile Coach and Certified Scrum Trainer
Scrum WithStyle scrumwithstyle.com

Scrum framework

© 2014 Scrum WithStyle scrumwithstyle.comCertified Scrum Product Owner
Rowan Bunning
• Government contract development (5 yrs)
• Product Development (5 yrs)
• Agile Training and Coaching (11 yrs)
• Agile Coach / ScrumMaster at leading Agile
consultancy in the U.K.
• Offer Agile Coaching services to enhance
Agile capability
• Industries: banking, media, real estate, food,
building security, data security, collection
management and content management
industries, government
• Accredited trainer in...
• Certified ScrumMaster®
• Certified Scrum Product Owner®
• Effective User Stories
• Agile Estimating and Planning

Goals for this session
• Give you ways of articulating how Scrum and Agile
can help us to better manage Risk
• Speciﬁc techniques from the Agile playbook that you
can emphasise in or add to manage the type of Risk
that you face

Key Points
• Good Scrum can give you a much better risk proﬁle
than Waterfall
• You can be more successful if you tune your Scrum
implementation to the types of risk that you face
• Various Agile techniques are geared toward
addressing different types of Risk

Outline
1. The R Word
2. Waterfallicies
3. Risk Categories
4. Scrum and XP Risk Management Strategies
5. Iterative Incremental Development (IID)
6. Potentially Shippable
7. Outcomes over Output
8. Release Planning
9. Sprint Planning
10. Visual Risk Management
11. Working with Conﬁdence
12. Experiment Driven Development
13. Lean Startup
14. Pairing
15. Changing the Game

The R word

Risks are known unknowns,
uncertainty is unknown
unknowns.
“Risk is rationalised fear.”
- Joseph Pelrine
“Risk is an uncertain event or condition that, if it
occurs, has a positive or negative effect on the
project’s objectives.”
- Project Management Body of Knowledge

Risk has an unknown outcome, but
we know what the the underlying
outcome distribution looks like.
we know the potential outcomes in advance, and
we may even know the odds of these outcomes
in advance. Graph credit: chrisbeales.net

Uncertainty is risk that
is immeasurable.
Business decisions, for example, deal with situations which
are far too unique, generally speaking, for any sort of
statistical tabulation to have any value for guidance. The
conception of an objectively measurable probability or
chance is simply inapplicable. The confusion arises from the
fact that we do estimate the value or validity or dependability
of our opinions and estimates, and such an estimate has the
same form as a probability judgment; it is a ratio, expressed
by a proper fraction. But in fact it appears to be meaningless
and fatally misleading to speak of the probability, in an
objective sense, that a judgment is correct.
- Economist Frank Knight in Risk, Certainty and Proﬁt (1921)

Agile Management
With Rowan Bunning,
Agile Coach and Certified Scrum Trainer
Scrum WithStyle scrumwithstyle.com
Uncertainty
^
X

- Tom DeMarco & Timothy Lister,
Waltzing with Bears, Dorset House 2003.

PotentialReward
Potential Risk
Upside risk
“Nothing ventured,
nothing gained.”

"It’s difﬁcult to make predictions,
especially about the future.”
- Danish politician Karl Kristian Steincke (1948)

You can’t eliminate risk
youtube.com/watch?v=GfBLbo08-fQ

Risk Management
“Risk Management's goal is to increase the impact
and probability of positive risks and decrease them
for negative risks.”
- Project Management Body of Knowledge
“Risk Management is project management
for adults.”
- Tom DeMarco & Timothy Lister

Waterfallicies

How the relay race began...
Dr Winston Royce, Managing the
Development of Large Software Systems, 1970.

What Royce said about this model
“I believe in this concept, but the
implementation described above
is risky and invites failure.”
Dr Winston Royce, Managing the
Development of Large Software Systems, 1970.

Royce recommended Iteration

Walker Royce re his father
“He [my father] was always a proponent of iterative,
incremental, evolutionary development. His paper
described the waterfall as the simplest description, but
that it would not work for all but the most straightforward
projects. The rest of his paper describes [iterative
practices] within the context of the 60s/70s government-
contracting models (a serious set of constraints).”
Walker Royce
(son of Winston Royce)
His book…

Systemic problems with Waterfall
This is far too
late to start
checking
quality!
Some of this
will be
wrong
Some of this
will be
unnecessary

Requirements vs Knowledge
and the end of a project?start of a project
How does our knowledge change between the
OpsAnalysis Design Coding Testing
Quantity of
requirements produced
at the time
Source: Kenny Rubin innolution.com.
Cumulative knowledge

Risk Categories

Risk categories
Are we developing the right thing?
Can these people develop it?
Will our solution work?
Do we understand the cost  
& timing?

Scrum and XP Risk
Management Strategies
Feedback at all levels and frequencies

Risk reduction using Scrum
Risk of... Scrum Strategy
Not pleasing the customer Customer sees product constantly.
Customer on-site.
Not completing all
functionality
Develop in priority order.
Poor estimating and
planning
Small estimates tracked daily.
Review and adjustment every
iteration.
(multiple)
Not resolving issues
properly
Active daily management.
Bi-directional reporting.
(multiple)
Not being able to
complete the development
cycle
Delivery of working software
every iteration.
Team forced to confront issues
early.
Taking too much work and
changing expectations
Clear goal and scope each
iteration.
No change within iterations.
Source: Schwaber, K., Beedle, M., Agile Software Development with Scrum, Prentice Hall, 2001.

Scrum risk management
Customer sees
product constantly.
Develop in
priority order.
Small estimates tracked daily.
Review and adjustment
every iteration.
Active daily management.
Bi-directional reporting.
Delivery of working
software every
iteration.
Clear goal and scope
each iteration.
No change
within iterations. Team forced to
confront issues
early.

Scrum & XP Feedback Loops
Months
Weeks
Days
Hours
________
________
________
________
________
________
________
_____
Release Review & Plan
Sprint Review & Plan
Acceptance Test
Daily Scrum
One Day
Pair Negotiation
Unit Test
Minutes
Code
Pair Programming
Seconds

And now for the news…
youtube.com/watch?v=lAvCbWANeY0

Iterative Incremental
Development (IID)
Incremental value addition, incremental risk reduction

Increment
• Means “add onto”
• A staging strategy through
“Product Increments”
• Contrasts with “big bang”
delivery
52 3
Source: Jeff Patton. www.AgileProductDesign.com
41

Keep a working system
every step of the way

Comparing approaches
Scrum - Iterative Incremental
Initiation
Requirements
Gathering
Design Code Test Fix Deploy
Baseline Code Complete Stabilised
Go Live #1
Cycle time to potentially shippable product
Waterfall - Sequential activity-based phases
Quality known
1 Month 2 Months 3 Months 4 Months 5 Months 6 Months 7 Months 8 Months
Sprint 1
Cycle time to potentially
shippable product
Release
Planning
Sprint 2 Sprint 3 Sprint 4 Sprint 5

Waterfall and risk impact
Requirements
Analysis
Design Code
Integrate &
System Test
Potential
Impact of
Risks being
tackled
Time
Highest risk activities such as
integration, system testing,
load testing are tackled late
First build and deliver
Source: Craig Larman, Agile & Iterative Development, 2004.

IID and risk impact
Potential
Impact of
Risks being
tackled
Time
All activities are
tackled early
Iterations
First build and deliver
Analysis
Design
Code
Integrate &
System Test
Analysis
Design
Code
Integrate &
System Test
Analysis
Design
Code
Integrate &
System Test
Analysis
Design
Code
Integrate &
System Test
Analysis
Design
Code
Integrate &
System Test
Source: Craig Larman, Agile & Iterative Development, 2004.

Create a safe-fail environment

Iterate
• Means “re-do” (to reﬁne)
• Develop a rough version, inspect
it, then improve it
• Allows evolution from vague idea
to a high quality realisation
1 2 3 4 5
Source: Jeff Patton. www.AgileProductDesign.com

Combining Iterative and
Incremental
• Provides more options
• Caters for both relatively well understood
and less understood elements
1 5 63 42

Potentially Shippable
Ready to go, as you go

Sashimi - slices that are complete

Coded
Depth of Done represents capability
Analysed
Designed
Load tested
Usability reviewed
Planned
Unit Tested
Functionally tested
Smoke Tested
Acceptance tested
Deployed
Training material
updated

“Undone” work represents risk
Stabilisation
Planned Release
Release delayed!
Sprint 1 Sprint 2 Sprint 3
Undone
Reference: Ken Schwaber.
UndoneUndone

Business Value
100
%BusinessValuedelivered
90
80
70
60
50
40
30
20
10
0
1 Month 2 Months 3 Months 4 Months 5 Months
Agile
with PSPI
Waterfall

%Uncertainty/Riskremaining
1 Month 2 Months 3 Months 4 Months 5 Months
Uncertainty/Risk
100
90
80
70
60
50
40
30
20
10
0
Waterfall
Agile
with PSPI
With a Potentially Shippable Product at
the end of every Sprint…
Risk = Business Value not yet delivered

Outcomes over Output
“Would you rather have your initial feature
set or a successful product?”
- Joseph Pelrine

Feature usage
Seldom or
never used 64%
Always or often
used 20% Always
Often
Sometimes
Seldom
Never
Reference: CHAOS Report, Standish Group.
Features in software systems

Inverting the constraint triangle
Constraints
Plan
Driven
Scope
Value
Driven
Cost Schedule
Traditional Agile
Estimates Resources Schedule
The plan creates
cost/schedule estimates
Features
The vision creates
feature estimates
Quality
Quality

we have come to value…
Outcomes over Outputs

Integrated Beneﬁts
Realisation
Agile’s big idea…

Impact Mapping
Goal
Actors who can inﬂuence
the outcome
Deliverables
(commonly Features)
Impacts to be created
Source: Impact Mapping: Making a big impact with software products and projects by Gojko Adzic, Provoking Thoughts (2012).

Example Impact Map
Thanks to: Paul Flewelling theagilecoach.co.nz

Release Planning
Rapid, rich, collaborative

Risk first release strategy
Growth of
knowledge
Strategy Reduce Risk Build out value Refine
Approach
Develop a simple system
span of necessities
Build out flexibility and
safety
Refine with comfort,
performance and
luxury
Pay to learn
Source: Jeff Patton www.agileproductdesign.com.
✄
Potential to
‘trim the tail’
Shine & gloss
Business value

Do that and you’re likely to…

Multi-pass iteration on product
Time (user experience flow)
Purchasing
Product
Selection
Product
Discovery Fulfilment
Necessity
The walking skeleton
more
necessary
less
necessary
Smallest set of
minimalist features to
be barely useable
Second pass - some flesh on the bones
Third pass
Fourth pass
Thanks to: Jeff Patton www.agileproductdesign.com.

Release early, release often
Thanks to: Jeff Patton www.agileproductdesign.com.
Time (user experience ﬂow)
Purchasing
Product
Selection
Product
Discovery Fulﬁlment
Necessity
more
necessary
less
necessary
Release: Beta
Minimum Marketable Product (MMP)
Release: 1.0

Collect these during Release Planning
Assumptions Open QuestionsRisks
Risk discovery

Risk chart
Risk
Likelihood
Impact
Exposure analysis

Collaborative Risk Board
Exploit/Reduce
Risks Strategy
Share/Transfer
Avoid
Accept
Reference: Slinger, M., Broderick, S., The Software Project Manager’s Bridge to Agility, Addison Wesley, 2008.
don’t do part of the project
that entails the risk e.g.
avoid platform upgrade
take steps before the risk materialises to
reduce impact or likelihood e.g. enhance
algorithm to process higher volume
no action but a contingency plan e.g.
do not code for data protection but
rely on backups
share risk with
other parties in
return for a sha
or fee e.g.
outsource

Choosing risk management strategy
Reduce
Reduce
Likelihood
Avoid
Avoid
Exploit
Exploit
Exploit
Exploit
ShareAcceptTransfer
High
Low
Threat Opportunity
Reference: Alan Moran, 2014 agileatlas.org/articles/item/embrace-risk-agile-risk-management

Sprint Planning
Drawing out the right conversations
about risk-related considerations

In pairs discuss:
What do you do during Sprint
planning to deal with Risk?
Risk-related activity during
Sprint Planning

Risk Identiﬁcation
What is the riskiest thing
we’re planning for this Sprint?
Imagine that we are at the end of
the Sprint and an Item did not get
to Done. Which Item was it?

Sprint Backlog Ordering
What dependencies do we have
between Items?
Given these dependencies and risks,
what is the best order to play these
Product Backlog Items in?

Contingency planning
When in the Sprint are we
likely to know whether X is
feasible?
If it turns out that X is not
feasible, what will we do?

Visual Risk
Management
Make risk visible

Making risk explicit on story cards
ID: Parent:
Started:
Done: Confidence: Size estimate:
Value estimate:Risks:
Themes:
scrum with style .com
Contact:

Ordering your Sprint by Risk
To Do
Backlog Items
To Do
Tasks
Work In
Progress
Done
Backlog Items
Completed
Tasks
Impeded
Higher risk
Lower risk

Risk on the card wall
To Do
Backlog Items
To Do
Tasks
Work In
Progress
Done
Backlog Items
Completed
Tasks
Impeded
Impediment
1/10/14 _/_/_
Risk Story

Risk story
As a result of upgrading the database
server, our application may stop working,
which would lead to an outage.
As a result of <definite cause>,
<uncertain event> may occur, which
would lead to <effect on objective(s)>
Reference:Alan Moran, Agile Risk Management, Springer, 2013.

Working with
Conﬁdence

Surfacing Risk when Estimating
Anxiety
Risk
Information
Source: Joseph Pelrine.
Conﬁdence Level:
very low very high
1 2 3 4 5

Accuracy vs Precision
“It’s better to be roughly right
than precisely wrong.”
- John Maynard Keynes

1.Inclusion in Release
2.Product Backlog Ordering
3.Commitment
4.Execution
Level of precision needed is contextual
Level of
precision
needed
Low
High
Decision type

Estimate size, derive duration
Velocity  
= 16
160
points
160/16
= 10 Sprints
?Calculation DurationSize
160 kms
Velocity  
= 80 km/h
160/80
= 2 hrs
Insert
measurement
from reality

Velocity as a range
Source: Mike Cohn.
0
10
19
29
38
1 2 3 4 5 6 7 8 9
Mean (Best 3) = 18
Mean (Last 8) = 16
Mean (Worst 3) = 14
Sprint
20
15
10
5
0

Forecasting number of sprints
Source: Mark Summers, Redeﬁning the traditional view of risk, Munich Scrum Gathering, October 2009.

Relative probability by sprint

Presenting cumulative probability
$
$
$
$

Understanding the Burndown chart
youtube.com/watch?v=HV76WzqpSI0

Burndown chart
Work
remaining
Time
Velocity is a trend of work
over time that emerges

Seeing Risk in the Sprint
0.0
22.5
45.0
67.5
90.0
1 2 3 4 5 6 7 8 9 10 Time
Work
remaining
Risk
Day
A
B
C
D
E
F
G

Release later with
more?
or
Release sooner
with less?

Fixed-scope scenario
Time
Features
I want this 
much. When  
can I get it?
More
Best case Worst case
Will not be Will beMaybe
Less
LongerShorter

Enhanced Release Burndown with variable
Scope
Reference: mountaingoatsoftware.com/agile/scrum/release-burndown/alternative
Work
remaining
Time
Sprint 1 S2 S3 S4 S5
Velocity
Range
Revised end point
S8
Original Release Forecast
Revised Release
Forecast
S7S6
Additional
items added
{

Fixed-date scenario
Time
Features
We need it on this
date. How much can
we have by then?
Best case
Worst case
Won’t have
Will have
May have
Less
More

Projecting Risk against Product Backlog
Reference: mountaingoatsoftware.com/agile/scrum/release-burndown/alternative
Fixed date
Work
remaining
Time
Sprint 1 Sprint 2 Sprint 3 Sprint 4
Reporting
Aﬃliates
Will have
Won’t have
Might Have
Reviews
Sprint 5
Velocity
Range
Catalogue
Cart
Checkout
✓
✓
✓
Fulﬁlment

Experiment Driven
Development

Experiment Driven Development model

Lean Startup

Testing viability of a
Business Hypothesis
The question is not
"Can this product be built?" Instead, the questions are
"Should this product be built?" and
"Can we build a sustainable business around this set
of products and services?”
Source: theleanstartup.com/principles

Lean Startup model

"Scrum’s Uncertainty Principle is:
Customers don’t know what they want
until they see it, and they always
reserve the right to change their mind."
- Jeff Sutherland, Emergence of Essential Systems

Pairing

The bus factor is the total number of key developers
who would need to be incapacitated to send the project
into such disarray that it would not be able to proceed.
- en.wikipedia.org/wiki/Bus_factor

Amplify Learning through Pairing
Photo: Calqui

Changing the Game
“Traditional managers view the plan
as the goal, whereas agile leaders
view customer value as the goal.”
- Jim Highsmith

Stakeholder satisfaction
Delivered at
agreed time
Within agreed
budget
Achieved
desired
outcome
Satisﬁed
stakeholders?
😃 / 😡 ?
✔ ❌ ❌ 😡
❌ ✔ ❌ 😡
❌ ❌ ✔ 😃
Thanks to: Jeff Patton.

What if you gave this to the customer?

Instead of playing not to lose…

…play to win!!!
FC Barcelona, 112 goals in 38 games

PotentialReward
Potential Risk
Be an upside risk seeker!
“Nothing ventured,
nothing gained.”

Recommended reading
Tom DeMarco,
Timothy Lister
Eric Ries
Alan Moran
Few People Understand The Difference Between Risk And Genuine Uncertainty
businessinsider.com.au/difference-between-risk-and-uncertainty-2013-3
Difference Between Risk and Uncertainty
keydifferences.com/difference-between-risk-and-uncertainty.html
Michele Sliger,
Stacia Broderick
now Stacia Heimgartner

Workshops
The Responsibility Process® Leading and Coaching
workshop (1 day)
Sydney Workshop Sept 25
Sydney Train the Trainer Sept 26
Melbourne Workshop Sept 19
Melbourne Train the Trainer Sept 20
Agile Fluency Game Workshop (2 days)
Sydney Sept 18-19
Melbourne Sept 25-26
Adelaide Sept 28 (1 day)
More info: scrumwithstyle.com

@rowanb au.linkedin.com/in/rowanbunning
Rowan Bunning
rowan@scrumwithstyle.com scrumwithstyle.com

Agile Risk Management

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (20)

Semelhante a Agile Risk Management

Semelhante a Agile Risk Management (20)

Mais de Rowan Bunning

Mais de Rowan Bunning (16)

Último

Último (18)

Agile Risk Management