Escaping the Waterfall: Reducing Risk with Agile Development with Scrum

3,445 views
3,264 views

Published on

Advocates of agile development claim that agile software projects succeed more often than plan-driven projects. Unfortunately, attempts to validate this claim statistically are problematic, because "success" is not defined consistently across studies. This paper addresses the question through a mathematical analysis of these projects. We model agile and plan-driven software projects with identical requirements, and show how they are affected by the same set of unanticipated problems. We find that that the agile project provides clear benefits for return-on-investment and risk reduction, compared to the plan-driven project, when uncertainty is high. When uncertainty is low, plan-driven projects are more cost-effective.

Published in: Education
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,445
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide
  • One of Albert Einstein’s favorite expressions. It means “thought experiment.” A gedanken experiment is a description of an experiment that could in principle be conducted. The purpose is to gain deeper understanding of a theory or question.
  • Candy Point: Give / toss a candy to each audience person who speaks, until we run out.
  • Escaping the Waterfall: Reducing Risk with Agile Development with Scrum

    1. 1. The Price of Uncertainty: Why Agile Projects Succeed when Others Fail<br />cPrime, Inc.<br />4100 E. Third Ave, Suite 205<br />Foster City, CA 94404<br />650-931-1651<br />www.cprime.com<br />
    2. 2. Today’s Presenters<br /><ul><li>Kevin Thompson, Ph.D. </li></ul>Senior Agile Instructor & Consultant<br /><ul><li>Trains, mentors Scrum teams and companies
    3. 3. Education and certifications
    4. 4. Certified ScrumMaster and Scrum Professional
    5. 5. Project Management Professional
    6. 6. Doctorate in Physics, Princeton University
    7. 7. Michael Sodano</li></ul>Vice President, Consulting Services<br /><ul><li>Responsible for overall quality across all cPrime solutions & clients
    8. 8. 15 Years Program / Project Management Experience
    9. 9. Education and certifications
    10. 10. Certified ScrumMaster
    11. 11. Does not have a Doctorate in Physics from Princeton University</li></ul>2<br />
    12. 12. Today’s Agenda<br />Introduction<br />Case Study: Well Planned Failure<br />Doing the Math<br />Lessons Learned<br />Case Study: How It Might Have Succeeded<br />Conclusion<br />3<br />
    13. 13. Outline<br />Introduction<br />Case Study: Well Planned Failure<br />Doing the Math<br />Lessons Learned<br />Case Study: How It Might Have Succeeded<br />Conclusion<br />4<br />
    14. 14. Introduction<br />Everyone talks about uncertainty,…<br />… but no one does anything about it.<br />That’s because you can’t eliminate it<br />You can only reduce some of it,…<br />… and cope with the rest<br />Many claim that agile projects work better than waterfall projects when uncertainty is high<br />Is this true?<br />We will see…<br />5<br />
    15. 15. Outline<br />Introduction<br />Case Study: Well Planned Failure<br />Doing the Math<br />Lessons Learned<br />Case Study: How It Might Have Succeeded<br />Conclusion<br />6<br />
    16. 16. Case Study: Well Planned Failure - Context<br />The year was 1995….<br />6 Months have gone by since NetMarket performed the first secure credit card transaction on the web – sold a C.D. for $12.48<br />The top billboard hit was Coolio’sGangsta Paradise <br />The #2 billboard hit was……<br />Waterfalls by TLC<br />After 3 Months in the Bay Area<br />7<br />
    17. 17. Case Study: Well Planned Failure - Background<br /><ul><li>2 Primary Internal Customers – Provisioning & Customer Service
    18. 18. Governance Model included PMO, & 5 Primary teams: (Architecture, Development, Business Analysis / Process, Change Management / Training Testing)
    19. 19. 300+ resources, 1 location
    20. 20. 1.5 year Timeline
    21. 21. Complete Executive Buy-In</li></ul>Company: National TeleCom Provider<br />Program Objective : Develop a Custom, GUI based Provisioning and Service Application<br />Methodology: Waterfall<br />8<br />
    22. 22. Case Study: Well Planned Failure – The Plan<br />1994<br />1995<br />‘96<br />Oct<br />Nov<br />Dec<br />Jan<br />Feb<br />Mar<br />Apr<br />May<br />Jun<br />Jul<br />Aug<br />Sep<br />Oct<br />Dec<br />Jan<br />Nov<br />Planning<br /><ul><li> Program Set-Up
    23. 23. Sourcing
    24. 24. Requirements Gathering</li></ul>Design<br /><ul><li> Wireframes
    25. 25. Experienced App Engineers
    26. 26. Experienced Architects</li></ul>Develop<br /><ul><li> JAD Sessions – to start
    27. 27. Closed development going forward</li></ul>Test / Train<br /><ul><li> Not what the customer wanted
    28. 28. Too SLOW
    29. 29. Too many manual interventions
    30. 30. Round the clock testing
    31. 31. Professional Trainers</li></ul>9<br />
    32. 32. Case Study: Well Planned Failure -Gap Analysis<br />What Was Delivered<br />What They Wanted<br />OOPS!<br />10<br />
    33. 33. Case Study: Well Planned Failure – The New Plan<br />1996<br />Jan<br />Feb<br />Mar<br />Apr<br />May<br />Jun<br />Jul<br />Aug<br />Sep<br />Oct<br />Dec<br />Jan<br />Nov<br />Re-Planning<br />$42 <br />Million Dollars Spent<br /><ul><li> Program Re-Org
    34. 34. Extend Resourcing
    35. 35. New Requirements Gathering</li></ul>Re-design<br /><ul><li> New Wireframes
    36. 36. Tired Experienced App Engineers
    37. 37. Bitter Experienced Architects</li></ul>Re-Develop<br /><ul><li> JAD Sessions – Throughout</li></ul>Test / Train<br /><ul><li> New CIO
    38. 38. Too Much Money Spent
    39. 39. Dissention on Actual Value
    40. 40. Round the clock testing
    41. 41. Professional Trainers</li></ul>11<br />
    42. 42. Outline<br />Introduction<br />Case Study: Well Planned Failure<br />Doing the Math<br />Lessons Learned<br />Case Study: How It Might Have Succeeded<br />Conclusion<br />12<br />
    43. 43. The Theories<br />Agile (Scrum) processes succeed where Waterfall processes fail<br />This is a big claim<br />It sounds arrogant<br />Promoters are often pushy and ideological<br />A carefully-planned waterfall process is the most efficient and successful way to run a project<br />This is a big claim<br />It sounds arrogant<br />Promoters are often pushy and ideological<br />13<br />
    44. 44. The Statistics<br />Standish Report © 2009<br />Surveyed 50,000 projects<br />Found<br />29% succeeded<br />53% late, over budget, lacked functionality or quality<br />18% failed<br />Dr. Dobb’s Journal (2007—2008), by Scott Ambler<br />586 people responded to the survey<br />Found<br />63% of waterfall projects succeed<br />72% of agile projects succeed<br />Agile looks better<br />But waterfall isn’t a disaster<br />Can we trust the statistics? What should we believe?<br />14<br />
    45. 45. Why we don’t Trust Statistics<br />Statistics can lie<br />There are lies, damn lies, and statistics<br />Select your truth, find statistics to back it up<br />“Who are you going to believe? Me, or your lying eyes?”<br />Math does not lie<br />Results are provable<br />Can assumptions can be wrong?<br />Yes<br />Take nothing on faith<br />So put theories to the test!<br />15<br />
    46. 46. Doing the Math<br />GEDANKEN EXPERIMENT<br />16<br />
    47. 47. Put the Theories to the Test!<br />Design a Gedanken Experiment to test the success of Scrum and Waterfall projects<br />Build mathematical models for each<br />Conduct the experiment<br />Learn from the results<br />17<br />
    48. 48. Experiment: Build a Data Warehouse / BI System<br />A company wants to provide a reporting (Business Intelligence) capability for customers<br />The initial concept calls for six reports<br />Basic tasks<br />Build production environment<br />Configure servers with database, reporting software<br />Create DB tables in various environments<br />Develop ETL processes to transfer data to reporting DB<br />Write reports<br />18<br />
    49. 49. System Architecture<br />OLTP (Online Transaction Processing) database<br />Stores data from company’s business applications<br />Replicated source DB<br />Contains copies of OLTP data needed for reports<br />Staging DB<br />ETL (Extract-Transform-Load) process transforms source data into this DB, whose design is appropriate for report generation<br />Report DB<br />Replication of staging DB, used only by the reporting software<br />Report server<br />Reporting application. Generates reports created by developers.<br />19<br />
    50. 50. Build the System in Two Ways<br />Two types of project<br />One big “Waterfall” project<br />An “Agile” project with six iterations<br />Only difference is scheduling!<br />One big project versus six iterations<br />Other agile practices are not considered<br />Both are subject to same constraints<br />Requirements have been set<br />Team sizes are the same<br />Funding is available for one year<br />Both are subject to the same uncertainties<br />See how they compare<br />20<br />
    51. 51. What Goes Wrong<br />Estimates are low<br />All planned work takes 25% more time than expected<br />Issue with source DB<br />Source table used by Report #2 has 80 million records. Special processing for table adds 3 weeks to schedule.<br />Upgrade<br />Reporting vendor upgrades app 10 months into the project. Upgrade required to fix critical bugs, adds 3 weeks to schedule.<br />Duplicate Data<br />Several source tables for Report #3 have duplicate data. Handling this problem adds 3 weeks to the schedule.<br />Production deployment is harder than expected. <br />Problems add 3 weeks to the schedule.<br />21<br />
    52. 52. Waterfall Project: The Planned Schedule<br />Predict the project will complete in about 9 months<br />Have room for three-month schedule buffer<br />22<br />
    53. 53. Agile Project: The Planned Schedule<br />Predict project will complete in 13 months<br />Pessimistic: Assumes 20% more effort per report than for Waterfall Project<br />Report #1: Takes 3 months, including initial server setup<br />Reports 2—5: Take 2 months each<br />Report #6: Won’t finish in Year 1<br />23<br />
    54. 54. Comparison: Plans for Waterfall and Agile Projects<br />Waterfall Project takes 9 months, Agile Project takes 13<br />Agile Project has more overhead<br />Waterfall Project is more efficient<br />Waterfall Project delivers all functionality in funding period<br />Agile Project runs out of money before completion<br />Requires de-scoping (remove Report #6)<br />Waterfall Project is clear winner<br />24<br />
    55. 55. Waterfall Project: The Actual Schedule<br />Add effects of uncertainty to 9-month schedule<br />Add 25% across the board: Expand to 11 months<br />Add four 3-week delays: Expand to 14 months<br />The money ran out at 12 months<br />The project was cancelled<br />The project failed<br />It delivered nothing<br />It produced no revenues<br />The entire investment was wasted<br />Money Spent + No Results = Lay off project team?<br />25<br />
    56. 56. Agile Project: The Actual Schedule<br /><ul><li>Add effects of uncertainty to 14-month schedule
    57. 57. Add 25% to all tasks
    58. 58. Add 3-week slips to first four reports
    59. 59. Total schedule expanded to 19 months
    60. 60. Three reports were delivered within Year 1</li></ul>26<br />
    61. 61. Schedule Comparison: Waterfall to Agile Project<br />Uncertainty impacted both projects<br />Schedules lengthened<br />14 months for the Waterfall Project (+44%)<br />19 months for the Agile Project (+36%)<br />Neither project delivered requested scope in Year 1<br />27<br />
    62. 62. Value Comparison: Waterfall to Agile Project<br />Within the budgeted one-year period<br />Agile Project delivered three working reports<br />Waterfall Project delivered no reports<br />By end of Year 1<br />Agile Project brought in revenues<br />Waterfall Project brought in nothing<br />Implications for Staff Retention / Growth<br />Agile project ROI encourages<br />Waterfall project’s zero ROI discourages<br />Implications for Year 2<br />Agile Project’s first-year revenues encourages extension<br />Waterfall Project stays canceled <br />28<br />
    63. 63. Outline<br />Introduction<br />Case Study: Well Planned Failure<br />Doing the Math<br />Lessons Learned<br />Case Study: How It Might Have Succeeded<br />Conclusion<br />29<br />
    64. 64. Lessons Learned<br />We can learn a lot from this gedanken experiment<br />Lessons revolve around how schedule relates to<br />Uncertainty<br />Risk<br />Return on investment<br />30<br />
    65. 65. Uncertainty Affects Return on Investment<br />When uncertainty is low, ROI is a calculation<br />Project takes X months, costs $Y, will yield $Z revenue<br />Estimate Net Present Value, Internal Rate of Return, etc.<br />When uncertainty is high, ROI is a gamble<br />Projects might not finish<br />Oops! It was late by factor of 3, then company went out of business<br />Funding might disappear<br />Business priorities changed. We’ll do rear-view mirrors, get out of tire business.<br />Customer interests can change<br />Last year’s best-selling Pet Rock is this year’s gravel<br />High uncertainty = high risk of wasting entire investment<br />31<br />
    66. 66. Manage Uncertainty by Reducing Risk…<br />Think of this visit to the doctor<br />Patient: “Doc, my back hurts when I lift heavy weights. What should I do?”<br />Doctor: “Lift smaller weights.”<br />Don’t make a few big investments over long periods and expect big returns<br />There may be no returns<br />You may lose all of your investment<br />32<br />
    67. 67. …and Speeding up Delivery of Value<br />Make small investments for short periods to get small returns<br />Risk is smaller with small investments<br />Losses are less painful, when they occur<br />Uncertainty is reduced due to shorter time periods <br />Less time and less scope for problems<br />Flexibility is greater<br />More opportunities to change direction<br />Large projected ROI is worthless if project never completes<br />Better to deliver some value, soon, than risk large value, never<br />Deliver increments of value as soon as possible<br />Early ROI in pieces is better than big ROI at end<br />Efficiency, later is seldom as important as value, soon<br />33<br />
    68. 68. Summary of Lessons Learned<br />In high-uncertainty projects<br />Risk of failure is high<br />Schedules can become meaningless<br />All-or-nothing plans invite disaster<br />Better to plan for the schedule to be wrong<br />Tailor strategy to perform even when schedule is toast<br />Change your plan to deliver value<br />Do not estimate schedule, plan to deliver all value at end<br />Ask, “How can I deliver the most value in…<br />The next [month | three months | six months]<br />Deliver planned scope in useful increments, ASAP<br />Value sooner is better than value later<br />Some value this year is better than a cancelled project<br />34<br />
    69. 69. Outline<br />Introduction<br />Case Study: Well Planned Failure<br />Doing the Math<br />Lessons Learned<br />Case Study: How It Might Have Succeeded<br />Conclusion<br />35<br />
    70. 70. Case Study: How It Might Have Succeeded<br />Divide project into short iterations<br />Deliver value with each iteration<br />Work closely with customer to validate deliverables<br />Adjust course based on feedback<br />Worst case: Cancel project early<br />Before wasting complete investment<br />36<br />
    71. 71. Outline<br />Introduction<br />Case Study: Well Planned Failure<br />Doing the Math<br />Lessons Learned<br />Case Study: How It Might Have Succeeded<br />Conclusion<br />37<br />
    72. 72. Conclusion<br />High-uncertainty projects drive “agile process frameworks” (such as Scrum)<br />Long-term, fixed-scope projects break when uncertainty is high<br />Small iterations bring big benefits<br />Risk reduction<br />Improved ROI through early delivery<br />38<br />
    73. 73. Crossing the Gap to an Agile World<br />The transition from Waterfall to Scrum can be difficult<br />No part is easy<br />“Easiest” part is changing how development work is done<br />Hardest parts include<br />Changing customer, stakeholder expectations about schedule commitments<br />Changing business process around the development work<br />Suggestions to ease the transition<br />Pick “low-hanging fruit” first<br />Plan more short projects, instead of long projects<br />Get training and mentoring for migration to Scrum<br />39<br />
    74. 74. Discussion<br />One “Candy Point” per speaker (while they last)<br />War Stories!<br />What projects failed? Why?<br />Success Stories!<br />What projects succeeded? Why?<br />Bonus questions (2 Candy Point for first right answer):<br />Who was Albert Einstein?<br />What does “gedanken” mean?<br />What is the key difference between the Special and General Theories of Relativity?<br />cPrime, Inc.<br />www.cPrime.com<br />650-931-1650<br />Educating. Consulting. Leading.<br />40<br />

    ×