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.

1. Waterfall into Scrum

2. Intro Chad “Uber Scrum Master” Holdorf Scrum Master / Program Manager: John Deere Certified Scrum Master and Product Owner Email: chadholdorf@gmail.com Blog: http://uberscrummaster.wordpress.com 2

4. Overview of Framework (Scrum)

5. How Scrum fits with current Waterfall processes3

7. Prior to Agile

8. 1 Release per year

9. Post Agile

10. 4+ Releases per year

11. Inovis- EDI/Business Software

12. Post Agile: < 1 Month per Release

14. Average Release in Person Months: 12PM

15. Industry Release Avg: 34PMMore Examples in Backup Section at End 4

16. What is this Agile/Scrum Framework? 5

18. Team

19. Scrum Master

20. Product Backlog

21. Sprint Backlog

22. Potentially Shippable Product

23. Burndown Charts

24. Sprint Planning

25. Sprint

26. Sprint Review

27. Retrospective6

28. Overview of Scrum Framework 7 Roles Product Owner Scrum Master Team Artifacts & Practices

30. Manages ROI through prioritization and release plans

31. Gets input from customers, end-users, team, managers, stakeholders, executives, industry experts when crafting the vision

32. Turns input into a single list of what should be produced, prioritized based on business value and risk

33. Owns the Product Backlog“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.” Product Owner Scrum Master Team 8

35. It can be played by an existing person (such as a former Project Manager or team-member).

36. Serves the team

37. Helping remove any and all impediments that surface

38. Protects the team

39. Teaches and guides the team’s use of Scrum

40. Facilitates – doesn’t “manage” (direct) the team“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.” Product Owner Scrum Master Team 9

42. Cross-functional - it has all the skills to produce the finished product

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. Authority to do whatever is necessary to meet it’s commitment

45. The ideal team size in Scrum is 7 people +/- 2“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.” Product Owner Scrum Master Team 10

47. Prioritized based on business value and risk, in the judgment of the Product Owner

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. Constantly being revised by the Product Owner, to maximize the business success of the team’s efforts

50. Product Backlog Items vary in size (typically 2-3 people, 2-3 days).11

51. Artifact:Product Backlog 12 Priority High-Level Est. Product Backlog Item

53. Team creates a task-level plan for how they will deliver

54. Team creates an initial assignment of tasks

55. Team compares total estimated task hours with total estimated available hours, to make sure the commitment is reasonable

56. Everyone on the team takes part, regardless of role and experience-level13

58. Managers may initially be concerned that their team might under-commit.

59. Many teams are initially concerned about the perception of the amount of work being completed, so they over commit.

60. In reality, most teams have the opposite problem: it may take them several Sprints to learn to not over-commit.14

62. Tasks include detailed estimate created by the team

63. Team tracks effort remaining to complete each task

64. Constantly being revised by the Team, to maximize achievement of the sprint goal

65. Tasks vary in size but no larger than 2 days15

67. Strictly time-boxed to 15 minutes

68. 3 questions: what was done since last meeting, what will be done by next meeting, and any issues/impediments

69. Scrum Master notes issues/impediments, and afterwards helps resolve them

70. Others can attend the meeting if the team invites them, but they do not speak. This meeting is not for monitoring the team16

72. The Burndown Chart graphs the total hours left for all tasks.

73. The Burnup Chart graphs the total number of backlog items completed in the Sprint.

74. These charts enable the team to successfully self manage and deliver what they committed to by the end of the Sprint. 17

75. Artifact:Burndown & Burnup Charts 18

77. For software, this means functionality that has been designed, fully implemented, and fully tested, with no major defects.

78. Few teams can produce Potentially Shippable Product from Sprint 1, but each Sprint they work to get closer to this goal.19

80. Product Owner, Team, Scrum Master, and Stakeholders come together and see a demo of what the team has produced

81. Product Owner gathers feedback from everyone on the ways to improve what has been built

82. Feedback is incorporated into the Product Backlog20

84. Method for identifying and addressing critical problems

85. Retrospective meeting requires the Team, Product Owner, and Scrum Master

86. Focuses on 3 questions:What worked well? What needs improvement? What action items do we implement in the next sprint 21

87. Typical Project Lifecycle 22

88. Scrum Shifts the Drivers 23 Traditional Project Scrum Project The plan creates cost / schedule estimates The vision creates scope estimates Fixed Budget Scope Schedule Plan Driven Value Driven Scope Budget Schedule Estimated

89. So how does the framework fit? 24

90. Waterfall vs. Agile 25 Scope Schedule Ch Ph2 Ph 3 Ph 4 Ph 5 Scope Analysis/Design Schedule Ph2 Ch Budget Code Ph 3 Component Test Ph 4 System Test Ph 5 End to End Small Slices of work 20% Done = 100% usable

91. 26 Sprints Align w/ Waterfall Exits Requirements Product Increments Phase Exits Value “Trimming the Tale” Time to move on Ph3 Charter Ph2 Ph4 Ph5 100% System Verification Goal is to remove this phase through automation Not all requirements are written Scope Teams “sprint” all the time Value is created quicker Schedule/Budget Team members dedicated

92. References Salesforce.com Agile Transformation Inovis - Reformulating the Product Delivery Process Project Management With Scrum 27