Using Agile techniques to manage risk more effectively

1,542
-1

Published on

Given that the "Waterfall" process model has been dominant in the IT industry for many decades, how many IT and project management professionals are aware that it's inventor warned the world in 1970 that Waterfall is "risky and invites failure"?

From a risk management perspective, is waterfall ever an appropriate choice for complex IT initiatives given what we know now?

In this session we will outline how, as a risk management strategy, using the waterfall model for non-trivial systems development initiatives is systemically high risk as compared with the Iterative Incremental Development (IID) model that has been used in pockets of the IT industry since the late 1950's. Today, many organisations use the IID strategy under the umbrella term of 'Agile'. The majority of these employ Lean Product Development patterns that were first described in the Harvard Business Review in 1986 using a metaphor borrowed from the game of rugby i.e. 'Scrum'.

If you are not using a disciplined agile approach, are you facing more risk as you approach a high-stakes deadline than you need to?

The varied contexts that we work in come with varied types of risk. For a green fields date-driven release, the primary risk may be cost and schedule related. For teams designing a new product for an emerging market, the primary risks may be business risk. For teams doing innovative R&D, the primary risk may technical risk. For a young team in a new technical or business domain, the primary risk may be social risk. In this session, we will use real world examples of such varied challenges to illustrate how risk-tuned Agile helped us to manage risk effectively.

Whilst we will always have to deal with risk to create value, the good news is that there are now many powerful risk management techniques that can be overlaid on top of IID to tune your development process to the type of risk you face. The question is: which ones are most appropriate for the type of risk you are facing? In this workshop we outline a series of powerful risk management tools that tune an agile development process to effectively manage the type of risk that you face.

0 Comments
14 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
1,542
On Slideshare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
0
Comments
0
Likes
14
Embeds 0
No embeds

No notes for slide

Using Agile techniques to manage risk more effectively

  1. 1. © 2014-5 Scrum WithStyle scrumwithstyle.com Using Agile techniques to manage risk more effectively With Rowan Bunning, Agile Coach and Certified Scrum Trainer Scrum WithStyle scrumwithstyle.com
  2. 2. © 2014-5 Scrum WithStyle scrumwithstyle.com Goals for this session a. Help you to articulate why Agile is smarter way to managing risk b. Bring to your attention specific techniques that you can emphasise within your Agile implementation to manage the types of risk that you face
  3. 3. © 2014-5 Scrum WithStyle scrumwithstyle.com Session Outline • What is Risk? • Risk Categories • Waterfallicies • Iterative Incremental Development (IID) • Scrum and XP Risk Management Strategies • Risk of developing the wrong product • Outcomes over Outputs using Impact Mapping • More minimal than MVP Story Mapping • The risk-reward game using entrepreneurial Product Ownership • The Potential of Potentially Shippable • Visual Risk Management • Sprint level risk management • Forecasting from real velocity • Reducing your ‘bus factor’
  4. 4. © 2014-5 Scrum WithStyle scrumwithstyle.com What is Risk?
  5. 5. © 2014-5 Scrum WithStyle scrumwithstyle.com What is Risk? “Risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on the projects objectives.” - Project Management Body of Knowledge “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
  6. 6. © 2014-5 Scrum WithStyle scrumwithstyle.com - Tom DeMarco & Timothy Lister, Waltzing with Bears, Dorset House 2003.
  7. 7. © 2014-5 Scrum WithStyle scrumwithstyle.com PotentialReward Potential Risk
  8. 8. © 2014-5 Scrum WithStyle scrumwithstyle.com Risk Categories
  9. 9. © 2014-5 Scrum WithStyle scrumwithstyle.com Risk categories Are we developing the right thing? Can the people involved deliver it? Is our solution technically feasible? Do we understand the cost 
 & timing?
  10. 10. © 2014-5 Scrum WithStyle scrumwithstyle.com Waterfallicies
  11. 11. © 2014-5 Scrum WithStyle scrumwithstyle.com How the relay race began... Dr Winston Royce, Managing the Development of Large Software Systems, 1970.
  12. 12. © 2014-5 Scrum WithStyle scrumwithstyle.com 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.
  13. 13. © 2014-5 Scrum WithStyle scrumwithstyle.com – Walker Royce (son of Winston Royce) “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).” His book…
  14. 14. © 2014-5 Scrum WithStyle scrumwithstyle.com 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
  15. 15. © 2014-5 Scrum WithStyle scrumwithstyle.com Iterative Incremental Development (IID) Incremental value addition, incremental risk reduction
  16. 16. © 2015 Scrum WithStyle scrumwithstyle.com Increment • Means “add onto” • A staging strategy through “Product Increments” • Contrasts with “big bang” delivery 52 3 Source: Jeff Patton. www.AgileProductDesign.com 41
  17. 17. © 2015 Scrum WithStyle scrumwithstyle.com Iterate • Means “re-do” (to refine) • 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
  18. 18. © 2014-5 Scrum WithStyle scrumwithstyle.com Banking story
  19. 19. © 2014-5 Scrum WithStyle scrumwithstyle.com
  20. 20. © 2014-5 Scrum WithStyle scrumwithstyle.com 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.
  21. 21. © 2014-5 Scrum WithStyle scrumwithstyle.com 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.
  22. 22. © 2014-5 Scrum WithStyle scrumwithstyle.com Scrum and XP Risk Management Strategies Feedback at all levels and frequencies
  23. 23. © 2014-5 Scrum WithStyle scrumwithstyle.com 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.
  24. 24. © 2014-5 Scrum WithStyle scrumwithstyle.com Scrum risk management Customer sees product constantly. Develop in priority order. Progress tracked daily. Review and adjustment every iteration. Active daily management. Bi-directional reporting. Delivery of working software every iteration. Risk identification and planning No change within iterations. Team forced to confront issues early.
  25. 25. © 2014-5 Scrum WithStyle scrumwithstyle.com 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
  26. 26. © 2014-5 Scrum WithStyle scrumwithstyle.com Risk of developing the wrong product using the Lean Startup model
  27. 27. © 2014-5 Scrum WithStyle scrumwithstyle.com Lean Startup model Persist vs Persevere? Dropbox static image
  28. 28. © 2014-5 Scrum WithStyle scrumwithstyle.com Outcomes over Outputs using Impact Mapping “Would you rather have your initial feature set or a successful product?” - Joseph Pelrine
  29. 29. © 2014-5 Scrum WithStyle scrumwithstyle.com 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
  30. 30. © 2014-5 Scrum WithStyle scrumwithstyle.com Inverting the iron triangle Constraints Plan Driven Scope Value Driven Cost Schedule Traditional Scrum Estimates Cost Schedule The plan creates cost/schedule estimates Features The vision creates feature estimates Quality Quality
  31. 31. © 2014-5 Scrum WithStyle scrumwithstyle.com we have come to value… 😀 💵 Outcomes over Outputs
  32. 32. © 2014-5 Scrum WithStyle scrumwithstyle.com Impact Mapping Goal Actors who can influence 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).
  33. 33. © 2014-5 Scrum WithStyle scrumwithstyle.com Example Impact Map Key assumption: cheaper IT operations would bring this saving Source: Impact Mapping: Making a big impact with software products and projects by Gojko Adzic, Provoking Thoughts (2012).
  34. 34. © 2014-5 Scrum WithStyle scrumwithstyle.com More minimal than MVP using Story Mapping
  35. 35. © 2014-5 Scrum WithStyle scrumwithstyle.com 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
  36. 36. © 2014-5 Scrum WithStyle scrumwithstyle.com Time (user experience flow) Necessity The walking skeleton more less Smallest set of minimalist features for skeleton product to be barely useable etc. Second pass putting flesh on the bones The ‘backbone’ Thanks to: Jeff Patton www.agileproductdesign.com. PurchasingProduct Selection Product Discovery Fulfilment Multi-pass iteration on product capabilities and quality
  37. 37. © 2014-5 Scrum WithStyle scrumwithstyle.com Thanks to: Jeff Patton www.agileproductdesign.com. Time (user experience flow) Necessity more less Release: 1.0 Minimum Marketable Product (MMP) Release: 1.1 PurchasingProduct Selection Product Discovery Fulfilment Release early, release often
  38. 38. © 2014-5 Scrum WithStyle scrumwithstyle.com Do this and you’re likely to… …sleep well at night as you near a deadline.
  39. 39. © 2014-5 Scrum WithStyle scrumwithstyle.com Collect these during Release Planning Assumptions Open QuestionsRisks for collaborative risk discovery
  40. 40. © 2014-5 Scrum WithStyle scrumwithstyle.com Risk chart Risk Likelihood Impact for collaborative risk exposure analysis
  41. 41. © 2014-5 Scrum WithStyle scrumwithstyle.com 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 for risk management
  42. 42. © 2014-5 Scrum WithStyle scrumwithstyle.com The risk-reward game using entrepreneurial Product Ownership
  43. 43. © 2014-5 Scrum WithStyle scrumwithstyle.com Nothing ventured, nothing gained.
  44. 44. © 2014-5 Scrum WithStyle scrumwithstyle.com Experiment Driven Development model
  45. 45. © 2014-5 Scrum WithStyle scrumwithstyle.com The Potential of Potentially Shippable Ready to go, as you go
  46. 46. © 2014-5 Scrum WithStyle scrumwithstyle.com Sashimi - slices that are complete
  47. 47. © 2014-5 Scrum WithStyle scrumwithstyle.com 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
  48. 48. © 2014-5 Scrum WithStyle scrumwithstyle.com %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 WaterfallAgile with PSPI With a Potentially Shippable Product at the end of every Sprint… Risk = Business Value not yet delivered
  49. 49. © 2014-5 Scrum WithStyle scrumwithstyle.com “Undone” work represents uncertainty and risk Stabilisation Planned Release Release delayed! Sprint 1 Sprint 2 Sprint 3 Undone Reference: Ken Schwaber. UndoneUndone
  50. 50. © 2014-5 Scrum WithStyle scrumwithstyle.com Visual Risk Management Make risk visible
  51. 51. © 2014-5 Scrum WithStyle scrumwithstyle.com Make risks explicit on story cards ID: Parent: Started: Done: Confidence: Size estimate: Value estimate:Risks: Themes: scrum with style .com Contact:
  52. 52. © 2014-5 Scrum WithStyle scrumwithstyle.com 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
  53. 53. © 2014-5 Scrum WithStyle scrumwithstyle.com 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
  54. 54. © 2014-5 Scrum WithStyle scrumwithstyle.com 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.
  55. 55. © 2014-5 Scrum WithStyle scrumwithstyle.com Sprint level risk management Managing Sprints to success
  56. 56. © 2014-5 Scrum WithStyle scrumwithstyle.com Risk Identification 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?
  57. 57. © 2014-5 Scrum WithStyle scrumwithstyle.com 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?
  58. 58. © 2014-5 Scrum WithStyle scrumwithstyle.com 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?
  59. 59. © 2014-5 Scrum WithStyle scrumwithstyle.com Burndown chart Work remaining Time Velocity is a trend of pace through work over time that emerges
  60. 60. © 2014-5 Scrum WithStyle scrumwithstyle.com 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
  61. 61. © 2014-5 Scrum WithStyle scrumwithstyle.com Forecasting from real velocity
  62. 62. © 2014-5 Scrum WithStyle scrumwithstyle.com Accuracy vs Precision “It’s better to be roughly right than precisely wrong.” - John Maynard Keynes
  63. 63. © 2014-5 Scrum WithStyle scrumwithstyle.com Surfacing Risk when Estimating Anxiety Risk Information Source: Joseph Pelrine. Confidence Level: very low very high 1 2 3 4 5 Agile estimating encourages us to be upfront about the uncertainty/risk associated with estimates
  64. 64. © 2014-5 Scrum WithStyle scrumwithstyle.com 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
  65. 65. © 2014-5 Scrum WithStyle scrumwithstyle.com Relative probability by sprint Source: Mark Summers, Redefining the traditional view of risk, Munich Scrum Gathering, October 2009.
  66. 66. © 2014-5 Scrum WithStyle scrumwithstyle.com Presenting cumulative probability $ $ $ $ Source: Mark Summers, Redefining the traditional view of risk, Munich Scrum Gathering, October 2009.
  67. 67. © 2015 Scrum WithStyle scrumwithstyle.com Fixed-scope scenario Time Features I want this
 much. When 
 can I get it? More Best case Worst case Won’t make it Will make it Might Make it Less LongerShorter
  68. 68. © 2015 Scrum WithStyle scrumwithstyle.com 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 Might have Less More
  69. 69. © 2014-5 Scrum WithStyle scrumwithstyle.com 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 Affiliates Will have Won’t have Might Have Reviews Sprint 5 Velocity Range Catalogue Cart Checkout ✓ ✓ ✓ Fulfilment
  70. 70. © 2014-5 Scrum WithStyle scrumwithstyle.com Reducing your ‘bus factor’ Agile knowledge sharing techniques
  71. 71. © 2014-5 Scrum WithStyle scrumwithstyle.com 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
  72. 72. © 2014-5 Scrum WithStyle scrumwithstyle.com Amplify Learning through Pairing Photo: Calqui
  73. 73. © 2014-5 Scrum WithStyle scrumwithstyle.com Collaborative modelling Image credit: less.works
  74. 74. © 2014-5 Scrum WithStyle scrumwithstyle.com Risk categories Are we developing the right thing? Can the people involved deliver it? Is our solution technically feasible? Do we understand the cost 
 & timing?
  75. 75. © 2014-5 Scrum WithStyle scrumwithstyle.com References Tom DeMarco, Timothy Lister Eric Ries Michele Sliger, Stacia Broderick Alan Moran Embrace Risk - Agile Risk Management http://agileatlas.org/articles/item/embrace-risk-agile-risk-management
  76. 76. © 2014-5 Scrum WithStyle scrumwithstyle.com Conclusions • Waterfall is ‘risky and invites failure’ • Iterative Incremental Development offers a far better risk profile • When approached in an entrepreneurial fashion, Scrum Product Ownership provides a way to manage high risk to realise high reward • The Agile and Scrum world offer many powerful techniques for risk discovery, analysis and management • Various Agile techniques are geared toward addressing different types of risk • Overall, Agile delivery is risk management
  77. 77. © 2014-5 Scrum WithStyle scrumwithstyle.com We’re@rowanb au.linkedin.com/in/rowanbunning Rowan Bunning rowan@scrumwithstyle.com scrumwithstyle.com

×