Managing Risk in Agile Development: It Isn’t Magic

AT2
Concurrent Session
11/12/15 10:00am

“Managing Risk in Agile Development: It Isn’t
Magic”

Presented by:
Thomas Cagley Jr.
DCG

Brought to you by:

340 Corporate Way, Suite 300, Orange Park, FL 32073
888-268-8770 · 904-278-0524 · info@techwell.com · www.techwell.com

Thomas Cagley Jr
DCG
With more than twenty years of experience in the software industry, Tom Cagley is DCG’s agile
process manager. Previously, Tom has held technical and managerial positions in different
industries as a leader in software methods and metrics, quality assurance, and systems analysis.
His areas of expertise encompass management experience in a wide variety of methods and
metrics—lean software development, agile software development, and quality and quality
assurance to achieve process improvements. Tom is a certified ScrumMaster, certified Scaled
Agile Framework Program Consultant, TMMi Accredited Assessor, IT-CMF Tier 2 Associate, and
holds an IT-CMF Professional Certificate.

Measure. Optimize. Deliver.
Phone +1.610.644.2856
Managing Risk in Agile Development:
It Isn’t Magic
Agile Development Conference East
November 12, 2015
©2015 David Consulting Group
Risk is any uncertain event that
can have an impact on the
success of a project.
1
Risk

Risk is the direct result of
uncertainty. If there is no
uncertainty, it is not a risk – it is
a certainty.
2
Risk and Uncertainty
©2015 David Consulting Group 3
A Second-Class Citizen?
•  There are too many other things to do
directly related to delivering
functionality.
•  Risk management processes are
driven by a need for an external
certification.
•  Common risks are continually
identified and nothing is done about
those risks.

•  With risk management, we attempt
to identify the things we don’t know
(the uncertainties) and quantify
them so that they can be managed.
– Identify
– Evaluate
– Categorize
– Prioritize
– Plan Mitigation
– Implement Mitigation
4
Classic Risk Management
Basis for Conversation: Agile
•  A basic tenet of Agile Methods is
that teams produce a continuous
series of usable software builds
in very short cycles called sprints.
•  Each build is assessed, issues
identified and the backlog of
tasks is reviewed and prioritized,
and the most important tasks are
scheduled for the next sprint.

Controllable Risk Contributors
•  Complexity in any problem is a reflection
of the number of parts to the problem,
how those parts interact and the level of
intellectual difficulty.
•  Size of project or release influences the
overall variability.
•  Ad hoc or uncontrolled processes
can’t deliver a consistent output.
•  People are chaotic by nature.
Another View of Risks
•  Tom DeMarco and Tim Lister identify five risk areas found on
most projects in their book, Waltzing with Bears:
– Intrinsic Schedule Flaw
– Specification Breakdown
– Scope Creep
– Personnel Loss
– Productivity Variance

•  Business Risk – Adapting to
business change.
•  Technical Risk – Fitting within
technology environment.
•  DevOps/Operational Risk –
Fitting within the organization’s
operational environment.
•  Process Risk – Fitting of
techniques for delivering value.
•  Organizational/People Risk –
Impact of an environment
populated by people.
8
A Common Agile Risk Taxonomy
Risk Agile Approach
Mitigating Schedule Flaw Scrum provides feedback loops to mitigate invalid
estimates. Teams update the release plan at the
end of every sprint.
Mitigating Specification
Breakdown
A scrum delivery team will work collaboratively
with the product owner to ensure alignment
between what is requested and how it can be
delivered.
Mitigating Scope Creep The product owner will evaluate the new backlog
items and decide what action to take: Add, delete,
trade-out in priority with other product backlog
items.
Mitigating Personnel
Loss
Self-organizing teams focus on problems
impacting work resulting in higher morale.
Mitigating Productivity
Variation
Agile teams address the performance at the end of
every sprint as part of the retrospective.
9
Agile Puts Basic Risks at Risk

A great deal of explicit risk
management becomes unnecessary
when a project uses an Agile
approach.
Mike Cohn, Mountain Goat Software
10
Managing Risk in Agile is Different
Traditional Scrum
Risk Management: PM works with
management and stakeholders to
determine what the risk management
approach will be for the project.
*formal documentation
Risk Management: Team works with
the product owner, delivery team, and
scrum master to determine what the
risk management approach will be.
*no or informal documentation
Risk Identification: Identify all risks
upfront at project initiation and
planning.
Risk identification is “Big planning up
front.” (BPUF)
*the project manager creates this
deliverable
Risk Identification: Identify risk on
multiple levels: Vision, roadmap,
release planning, sprint planning &
daily standup.
Risk is identified and mitigated daily
and at planning exercises.
*whole team is involved in scrum
ceremonies and transparency
11

Traditional Scrum
Risk Analysis: Review all of the risks
identified during the identification meeting
and perform quantitative and qualitative
analysis.
Prioritize risks by performing an exercise
of possibility and probability, scoring of
every risk.
*the project manager scores and
determine which risks to mitigate
Risk Analysis: Agile projects generally
focus on qualitative risk analysis because
of the sprint time boxes and constant
feedback loops provided in scrum or xP
Prioritization exercise for most likely risks
*scrum master facilitates seeing the risks
and determining what to do next
Risk Response Planning: Develop
options and actions for the risks creating
the biggest threats.
*the project manager
Risk Response Planning: Happens in
real-time as risk is identified.
*whole team
12
Traditional Scrum
Risk Monitoring and
Controlling: Status meetings are the
forum to discuss new risks and
updates to the risk identification list
*the project manager facilitates the
status meeting that is usually weekly
or monthly
Risk Monitoring and
Controlling: Transparency of the
delivery team’s work via task boards,
burndowns, daily standups, and end-of-
sprint reviews provide information and
forums for continuously monitoring risk.
*whole team is involved in risk
monitoring through their contributions to
the data and feedback loops in scrum
13

Recognizing Risks
•  Carve out time when you are developing
the backlog and ask as diverse a group as
possible to identify the potential problems.
•  Form a small team (consider the Three
Amigos) to interview stakeholders that
were not part of the planning exercise.
•  Gather risk data though surveys when the
program stakeholders are geographically
diverse.
•  Interview customers or potential
customers.
•  Periodically ask about risks either as an
agenda item or as a follow-on to standard
meetings.
Agile Framework
•  Identify knowable risks. Identify
the knowable risks when
generating the initial backlog.
•  Build mitigation for common
risks into the definition of done.
•  Generate stories for less
common risks and add them to
the projects backlog.
•  Review risks when grooming
stories
•  Carve out time during planning
to identify emerging risks.

Agile Risk Management: Approach 2
1.  Light Approach Influenced by Michael Lant
1.  Identification: SWOT Analysis (Initially during project
chartering, refresh at each planning exercise)
2.  Classify: At a story or defect level using a simple taxonomy
3.  Quantify: Performed by the respective SME, not PM
•  Impact: Measure of effect on a simple 1 – 5 (High) scale
(I reflect value or days)
•  Probability: Likelihood on a simple 1 – 5 (High) scale
4.  Rate: Matrix: 5 x 5
5.  ACT!
6.  Repeat
Critical
(25)
Requires1urgent1action
Requires1notifcation1of1responsible1executive1and1senior1executives
Tracked1as1soon1as1identifed1(add1story1to1backlog)
Serious
(151@120)
Requires1notifcation1of1all1senior1stakeholders
Monitored1and1reviewed1during1planning1sessions1
(add1story1to1backlog)
Moderate
(61@112)
Requires1notifcation1of1senior1manager
Monitored1and1reviewed1during1release1planning1sessions1
(add1story1to1backlog)
Moderate
(11@15)
Reviewed1Quaterly
Add1story1to1backlog1(low1priority)
5 5 10 15 20 25
4 4 8 12 16 20
3 3 6 9 12 15
2 2 4 6 8 10
1 1 2 3 4 5
1 2 3 4 5
Impact
Probability
17

•  Risk Census (Adapted from Mike Cohn)
– Develop a census that describes each risk (add each risk to
the product backlog)
– Estimate of how likely the risk is to occur
– Estimate the impact if the risk did occur
– Calculate the expected exposure to the risk, which is the
probability multiplied by the impact
– When
•  Create the risk census during project chartering
(Iteration Zero)
•  Update it quickly during subsequent planning meetings
Risk
Probability-
of-Risk
Size-of-
Loss-(Days)
Risk-
Exposure
Communications+through+human+capital+continue+to+
be+slow
20% 15 3
Historical+data+access+and+quality+of+data+ 30% 20 6
Data:++Tool+availability+and+work+arounds 70% 2 1.4
Funding+issues+(once+we+set+goals,+we+won’t+change+
them+until+we+have+a+chance+to+report+on+accurate+
data)
10% 15 1.5
Forced+mandates+cause+ineffective+communications+
and+inability+to+use+pilot+data+for+lessons+learned
20% 30 6
Misalignment+of+function+point+team+(time+
difference)
40% 5 2
Total+Exposure 19.9
19
Risk Census Example

0
10
20
30
40
50
60
70
80
90
100
1 2 3 4 5 6 7 8 9 10
Risk%Exposure%(Days)
Iteration
Risk%Burn%Down
Ideal%Line
Actual%Performance
20
Risk Burn-Down Chart
•  The risk burn-down chart is then created by plotting the sum of
the risk exposure values from the census.
Description An evaluation of the cost impact of risks that have not been un-
remediated.
Purpose Facilitate the management of the impact of probability weighted
net present value of un-remediated risk through transparency and
monitoring
Utilization The impact value of risk is monitored at specific points of the
program lifecycle. Where the cost impact of risk is above program
risk tolerance specific remediation, plans will be established to
reduce the estimated risk impact.
Data Required ∑ (Net Present Value of Un-remediated Risk)
Risk Tolerance
Calculation Value at Risk = Probability Weighted Net Present Value of
Estimated Cost Impact of Un-remediated Risk
Timing Work Unit Completion – Specific Points
Baseline Not Applicable
Industry Data None
0
200000
400000
600000
800000
1000000
1 2 3 4 5 6 7 8 9 10
Risk%exposure%(Dollars)
Iterations
Value%At%Risk
21
Value At Risk

ROAMing Risks
•  Resolved: The risk has been
answered and avoided or
eliminated.
•  Owned: Someone has accepted
the responsibility for doing
something about the risk.
•  Accepted: The risk has been
understood and the team has
agreed that nothing will be done
about it.
•  Mitigated: Something has been
done so that the probability or
potential impact is reduced.
Risks Are Managed Collaboratively

Risk Questions I Am Often Asked
•  Is there still a perception from business that Agile is riskier than
the familiar ways of doing things?
•  Agile can be a random walk. How can projects work without a
effective classic requirements management?
•  Contracting for Agile?
Questions . . .
Tom Cagley, CFPS, CSM
VP of Consulting
The David Consulting Group
t.cagley@davidconsultinggroup.com
(440) 668-5717
Software Process and Measurement Podcast
http://www.spamcast.net (or iTunes)
Software Process and Measurement Blog
http://tcagley.wordpress.com
25

Managing Risk in Agile Development: It Isn’t Magic

More Related Content

What's hot (20)

Viewers also liked (18)

Similar to Managing Risk in Agile Development: It Isn’t Magic (20)

More from TechWell (20)

Recently uploaded (20)

Managing Risk in Agile Development: It Isn’t Magic