Scrum: Waterfall Into Scrum

6,871 views
6,625 views

Published on

Here is a presentation I presented to management describing how waterfall transitions into scrum. Couldn’t have been done without slideshare.com slides. This is me giving back.

Published in: Technology
0 Comments
22 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,871
On SlideShare
0
From Embeds
0
Number of Embeds
350
Actions
Shares
0
Downloads
364
Comments
0
Likes
22
Embeds 0
No embeds

No notes for slide

Scrum: Waterfall Into Scrum

  1. 1. Waterfall into Scrum<br />
  2. 2. Intro<br />Chad “Uber Scrum Master” Holdorf<br />Scrum Master / Program Manager: John Deere<br />Certified Scrum Master and Product Owner<br />Email: chadholdorf@gmail.com<br />Blog: http://uberscrummaster.wordpress.com<br />2<br />
  3. 3. Agenda<br /><ul><li>Results
  4. 4. Overview of Framework (Scrum)
  5. 5. How Scrum fits with current Waterfall processes</li></ul>3<br />
  6. 6. What have been the results of other companies?<br />Increased Speed<br /><ul><li>SalesForce.com
  7. 7. Prior to Agile
  8. 8. 1 Release per year
  9. 9. Post Agile
  10. 10. 4+ Releases per year
  11. 11. Inovis- EDI/Business Software
  12. 12. Post Agile: < 1 Month per Release
  13. 13. Industry Avg: 6 Months per Release</li></ul>Increased Efficiency<br /><ul><li>Inovis Post Agile
  14. 14. Average Release in Person Months: 12PM
  15. 15. Industry Release Avg: 34PM</li></ul>More Examples in Backup Section at End<br />4<br />
  16. 16. What is this Agile/Scrum Framework?<br />5<br />
  17. 17. 3 Facets of the Framework (Scrum)<br />Roles<br />(Who)<br />Artifacts<br />(What)<br />Practices<br />(How)<br /><ul><li> Product Owner
  18. 18. Team
  19. 19. Scrum Master
  20. 20. Product Backlog
  21. 21. Sprint Backlog
  22. 22. Potentially Shippable Product
  23. 23. Burndown Charts
  24. 24. Sprint Planning
  25. 25. Sprint
  26. 26. Sprint Review
  27. 27. Retrospective</li></ul>6<br />
  28. 28. Overview of Scrum Framework<br />7<br />Roles<br />Product Owner<br />Scrum Master<br />Team<br />Artifacts & Practices<br />
  29. 29. Product Owner<br /><ul><li>Owns the vision of what should be produced to achieve business success
  30. 30. Manages ROI through prioritization and release plans
  31. 31. Gets input from customers, end-users, team, managers, stakeholders, executives, industry experts when crafting the vision
  32. 32. Turns input into a single list of what should be produced, prioritized based on business value and risk
  33. 33. Owns the Product Backlog</li></ul>“The Product Owner’s focus is ROI. The Product Owner directs the project, sprint by sprint, to provide the greatest ROI and value to the organization.”<br />Product Owner<br />Scrum Master<br />Team<br />8<br />
  34. 34. The Scrum Master<br /><ul><li>A new leadership role
  35. 35. It can be played by an existing person (such as a former Project Manager or team-member).
  36. 36. Serves the team
  37. 37. Helping remove any and all impediments that surface
  38. 38. Protects the team
  39. 39. Teaches and guides the team’s use of Scrum
  40. 40. Facilitates – doesn’t “manage” (direct) the team</li></ul>“The Scrum Master is responsible for the success of the project, and helps increase the potential for success by helping the Product Owner select the most valuable backlog items and by helping the Team turn that backlog into functionality.”<br />Product Owner<br />Scrum Master<br />Team<br />9<br />
  41. 41. The Team<br /><ul><li>Owns the production and engineering process
  42. 42. Cross-functional - it has all the skills to produce the finished product
  43. 43. Self-organizing and self-managing - it is responsible for making a commitment and managing itself to hit the goals (or get as close as it can)
  44. 44. Authority to do whatever is necessary to meet it’s commitment
  45. 45. The ideal team size in Scrum is 7 people +/- 2</li></ul>“The Team is responsible for managing itself and has the full authority to do anything to meet the sprint goal within the guidelines, standards, and conventions of the organization and of Scrum.”<br />Product Owner<br />Scrum Master<br />Team<br />10<br />
  46. 46. Artifact:Product Backlog<br /><ul><li>Single master list of features, functionality, and other work required
  47. 47. Prioritized based on business value and risk, in the judgment of the Product Owner
  48. 48. Items at the top of the list will be completed by the team first and should have more detail than lower priority items
  49. 49. Constantly being revised by the Product Owner, to maximize the business success of the team’s efforts
  50. 50. Product Backlog Items vary in size (typically 2-3 people, 2-3 days).</li></ul>11<br />
  51. 51. Artifact:Product Backlog<br />12<br />Priority<br />High-Level Est.<br />Product Backlog Item<br />
  52. 52. Practice:Sprint Planning Meeting<br /><ul><li>Team selects what it will commit deliver by the end of Sprint
  53. 53. Team creates a task-level plan for how they will deliver
  54. 54. Team creates an initial assignment of tasks
  55. 55. Team compares total estimated task hours with total estimated available hours, to make sure the commitment is reasonable
  56. 56. Everyone on the team takes part, regardless of role and experience-level</li></ul>13<br />
  57. 57. Practice:Sprint Planning Meeting<br /><ul><li>Product Owner must not pressure the team into committing to more than they think is doable.
  58. 58. Managers may initially be concerned that their team might under-commit.
  59. 59. Many teams are initially concerned about the perception of the amount of work being completed, so they over commit.
  60. 60. In reality, most teams have the opposite problem: it may take them several Sprints to learn to not over-commit.</li></ul>14<br />
  61. 61. Artifact:Sprint Backlog<br /><ul><li>Complete list of tasks required to meet the sprint goals and committed product backlog items
  62. 62. Tasks include detailed estimate created by the team
  63. 63. Team tracks effort remaining to complete each task
  64. 64. Constantly being revised by the Team, to maximize achievement of the sprint goal
  65. 65. Tasks vary in size but no larger than 2 days</li></ul>15<br />
  66. 66. Practice:Daily Standup<br /><ul><li>A short meeting daily to update each other on progress and surface impediments
  67. 67. Strictly time-boxed to 15 minutes
  68. 68. 3 questions: what was done since last meeting, what will be done by next meeting, and any issues/impediments
  69. 69. Scrum Master notes issues/impediments, and afterwards helps resolve them
  70. 70. Others can attend the meeting if the team invites them, but they do not speak. This meeting is not for monitoring the team</li></ul>16<br />
  71. 71. Artifact:Burndown & Burnup Charts<br /><ul><li>Each day, the team updates simple charts that show progress towards their Sprint goal.
  72. 72. The Burndown Chart graphs the total hours left for all tasks.
  73. 73. The Burnup Chart graphs the total number of backlog items completed in the Sprint.
  74. 74. These charts enable the team to successfully self manage and deliver what they committed to by the end of the Sprint. </li></ul>17<br />
  75. 75. Artifact:Burndown & Burnup Charts<br />18<br />
  76. 76. Artifact:Potentially Shippable Product<br /><ul><li>The goal for the team is to complete 100% of what they committed to, ideally an increment of Potentially Shippable Product at the end of each Sprint.
  77. 77. For software, this means functionality that has been designed, fully implemented, and fully tested, with no major defects.
  78. 78. Few teams can produce Potentially Shippable Product from Sprint 1, but each Sprint they work to get closer to this goal.</li></ul>19<br />
  79. 79. Practice:Sprint Review (Demo)<br /><ul><li>Performed at the end of each Sprint
  80. 80. Product Owner, Team, Scrum Master, and Stakeholders come together and see a demo of what the team has produced
  81. 81. Product Owner gathers feedback from everyone on the ways to improve what has been built
  82. 82. Feedback is incorporated into the Product Backlog</li></ul>20<br />
  83. 83. Practice:Sprint Retrospective<br /><ul><li>Critical for continuous improvement of team effectiveness
  84. 84. Method for identifying and addressing critical problems
  85. 85. Retrospective meeting requires the Team, Product Owner, and Scrum Master
  86. 86. Focuses on 3 questions:</li></ul>What worked well?<br />What needs improvement?<br />What action items do we implement in the next sprint<br />21<br />
  87. 87. Typical Project Lifecycle<br />22<br />
  88. 88. Scrum Shifts the Drivers<br />23<br />Traditional Project<br />Scrum Project<br />The plan creates<br />cost / schedule<br />estimates<br />The vision creates scope estimates<br />Fixed<br />Budget<br />Scope<br />Schedule<br />Plan Driven<br />Value Driven<br />Scope<br />Budget<br />Schedule<br />Estimated<br />
  89. 89. So how does the framework fit?<br />24<br />
  90. 90. Waterfall vs. Agile<br />25<br />Scope<br />Schedule<br />Ch<br />Ph2 <br />Ph 3<br />Ph 4<br />Ph 5<br />Scope<br />Analysis/Design<br />Schedule<br />Ph2 <br />Ch<br />Budget<br />Code<br />Ph 3<br />Component Test<br />Ph 4<br />System Test<br />Ph 5<br />End to End<br />Small Slices of work<br />20% Done = 100% usable<br />
  91. 91. 26<br />Sprints<br />Align w/ Waterfall Exits<br />Requirements<br />Product Increments<br />Phase Exits<br />Value<br />“Trimming the Tale” Time to move on<br />Ph3<br />Charter<br />Ph2<br />Ph4<br />Ph5<br />100%<br />System Verification<br />Goal is to remove this phase through automation<br />Not all requirements are written<br />Scope<br />Teams “sprint” all the time<br />Value is created quicker<br />Schedule/Budget<br />Team members dedicated<br />
  92. 92. References<br />Salesforce.com Agile Transformation <br />Inovis - Reformulating the Product Delivery Process<br />Project Management With Scrum<br />27<br />

×