Close to agile


Published on

a overview scrum introduction

Published in: Technology, Business
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Quality : Apple , BLZMondey: movie Is Deadline important
  • What did I get done yesterdayWhat will I get done todayAre there any impediments slowing my progress
  • Close to agile

    1. 1. Close to Agile-Scrum introduction<br />Wu Gang<br />iSAP, HPIT GADSC<br />
    2. 2. Before start<br />Have you touched Agile / Scrum before?<br />What do you want to learn from this session ? <br />
    3. 3. AGENDA<br />Why Agile <br />What is Agile<br />Agile Value<br />Agile Principle<br />Scrum<br />How Scrum <br />Scrum process<br />
    4. 4. Agile<br />
    5. 5. Why Agile<br />
    6. 6. Agile is popular<br />
    7. 7. IT realities<br />IT project delivered late 90% Aberdeen<br />IT project delivered over budget 50% Gartner<br />IT project that fail to meet objectives 50% Gartner<br />IT project cancelled prior to completion 30% Aberdeen<br />
    8. 8. Situation for tradition software Dev<br />35% project complete on-time within budget<br />31% project cancelled<br />64% feature rarely never used<br />
    9. 9. Complexity<br />Can you understand enough in the beginning?<br />
    10. 10. Losing information<br />2<br />3<br />4<br />5<br />1<br />8<br />9<br />10<br />6<br />7<br />6. This is document<br />1. Promise Made by Sales <br />7. This is Installation Package<br />2. Requirement Metioned by Customer<br />8. This is Cost<br />3. Requirement Understanded by Project Manager<br />9. This is Support<br />4. Design given by Designer <br />10. This is What Really Want by Customer<br />5. Coding performed by programer<br />
    11. 11. What is project success<br />Cover scope<br />On time (before dead line)<br />Under budget<br />
    12. 12. Definition of success has changed<br />Functionality<br />83% of respondents believe that meeting actual needs of stakeholders is more important that building the system to specific action <br />Quality<br />82% believe that delivering high quality is more important that delivering on time and on budget.<br />Money<br />70% believe that providing the best ROI is more important that delivering under budget<br />Schedule<br />58% believe that delivering when the system is ready to be shipped is more important that delivering on schedule<br />Source: software development project success survey, Scott Ambler , 2008<br />
    13. 13. Agile is moving into mainstream<br />
    14. 14. Waterfall VS. Agile<br />
    15. 15. Waterfall vs. agile - cont<br />Manage Change<br />
    16. 16.
    17. 17. Benefit of using agile <br />Delivers faster time to market<br />Increases productivity<br />Reduces cost<br />Easily adapts to changing requirements and priorities<br />Lowers cost of change<br />Provides better visibility into project progress<br />Reduces risk<br />Maximizes ROI<br />Reduces waste<br />Encourages higher quality and simpler code<br />Delivers business value early and often<br />Increases team morale<br />
    18. 18. Survey for scrum project<br />88% increase productivity<br />93% increase quality<br />83% increase stakeholder satisfaction<br />49% reduce cost<br />Agile Methodologies: Survey Results, by Shine Technologies, 2003<br />
    19. 19. Agile<br />
    20. 20. What is Agile<br />Ag-ile (adj.) Characterized by quickness, lightness and ease of movement; nimble<br />Agile is simple (not easy)<br />Agile is about doing the important things first and taking small steps<br />It’s about people, values, principles, and practices that foster team communication and learning and improving as you go along to regularly deliver customer value through working software<br />
    21. 21. Agile manifesto<br />1<br />3<br />2<br />4<br />Individuals and interactionsover processes and tools<br />Customer collaborationover contract negotiation<br />Working softwareover comprehensive documentation <br />Responding to changeover following a plan <br />
    22. 22. Agile Principles<br />Satisfy the Customer<br />Welcome Change<br />Deliver Frequently<br />Work as a Team<br />Motivate People<br />Communicate Face-to-Face<br />Measure Working Software<br />Maintain Constant Pace<br />Excel at Quality<br />Keep it Simple<br />Evolve Designs<br />Reflect Regularly<br />
    23. 23.
    24. 24. What is Scrum<br />
    25. 25. Scrum<br />
    26. 26. Scrum<br />
    27. 27. Scrum 100 words<br />Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time<br />It allows us to rapidly and repeatedly inspect actual working software ( every two weeks to one month).<br />The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features.<br />Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.<br />
    28. 28. What Scrum look like<br />
    29. 29. Scrum characteristics<br />Self-organizing teams<br />Product progresses in a series of time boxed Sprints<br />Requirements are captured as items in a list of Product backlog<br />No specific engineering practices prescribed<br />Uses generative rules to create an agile environment for delivering projects <br />One of the Agile processes.<br />
    30. 30. How Scrum<br />
    31. 31. Roles<br />Ceremonies<br />Artifacts<br /><ul><li>Product owner
    32. 32. Scrum Master
    33. 33. Team
    34. 34. Sprint
    35. 35. Sprint planning
    36. 36. Sprint review
    37. 37. Sprint retrospective
    38. 38. Daily scrum meeting
    39. 39. Product backlog
    40. 40. Sprint backlog
    41. 41. Burndown charts</li></li></ul><li>What Scrum look like<br />ScrumMaster<br />Product Owner<br />Image available at<br />Team<br />
    42. 42. Roles<br />Ceremonies<br />Artifacts<br /><ul><li>Product owner
    43. 43. Scrum Master
    44. 44. Team
    45. 45. Sprint
    46. 46. Sprint planning
    47. 47. Sprint review
    48. 48. Sprint retrospective
    49. 49. Daily scrum meeting
    50. 50. Product backlog
    51. 51. Sprint backlog
    52. 52. Burndown charts</li></li></ul><li>Product owner<br />What he is<br />Owner of project vision<br />Represents the customer<br />What he can do<br />Define features (according to vision)<br />Prioritize features (according to ROI)<br />Pick release dates<br />Give feedback<br />Manage stakeholders<br />Accept or reject results<br />Define Success<br />
    53. 53. Team<br />What he is<br />Typically 5-9 people<br />Cross functional<br />Full Time<br />Self-Organized<br />What he can do<br />Define tasks<br />Estimate effort<br />Develop product<br />Ensure quality<br />Evolve processes<br />Deliver Success<br />
    54. 54. Scrum master<br />What he is<br />Servant leader<br />Team protector<br />Troubleshooter<br />Scrum guide<br />What he can do<br />Remove impediments<br />Prevent interruptions<br />Facilitate the team<br />Support the process<br />Manage management<br />Ensure Success<br />
    55. 55. Pigs and Chickens<br />Product Owner<br />Scrum Master<br />Team Members<br />Users<br />Managers<br />Marketing<br />
    56. 56. Roles<br />Ceremonies<br />Artifacts<br /><ul><li>Product owner
    57. 57. Scrum Master
    58. 58. Team
    59. 59. Sprint
    60. 60. Sprint planning
    61. 61. Sprint review
    62. 62. Sprint retrospective
    63. 63. Daily scrum meeting
    64. 64. Product backlog
    65. 65. Sprint backlog
    66. 66. Burndown charts</li></li></ul><li>Product BackLog<br />The requirements<br />A list of all desired work on the project<br />Ideally expressed such that each item has value to the users or customers of the product <br />Prioritized by the product owner<br />Reprioritized at the start of each sprint<br /><ul><li>Ordered
    67. 67. Valued
    68. 68. Estimated</li></ul>Product Backlog<br />
    69. 69. Product backlog<br />
    70. 70. User stories<br />As a <user> I want <functionality>( so that <benefit> )<br />As a guest, I want to cancel a reservation,<br />As a hotel employee, I can run RevPAR reports so that I can help to improve the quality of service<br />
    71. 71. Typical fields<br />
    72. 72. Principle of create User story<br />Independent<br />Negotiable<br />Valued<br />Estimable<br />Small<br />Testable<br />
    73. 73. Sprint Backlog<br />Individuals sign up for work of their own choosing<br />Work is never assigned<br />Estimated work remaining is updated daily<br />Any team member can add, delete or change the sprint backlog<br />Work for the sprint emerges<br />If work is unclear, define a sprint backlog item with a larger amount of time and break it down later<br />Update work remaining as more becomes known<br /><ul><li>Assignable
    74. 74. Small (1-16hours)
    75. 75. Team Estimated</li></ul>Sprint Backlog<br />
    76. 76. Sprint BackLog<br />8<br />4<br />8<br />16<br />12<br />4<br />10<br />8<br />16<br />11<br />8<br />16<br />12<br />8<br />8<br />8<br />8<br />8<br />4<br />Add error logging<br />8<br />Tasks<br />Mon<br />Tues<br />Wed<br />Thur<br />Fri<br />Code the user interface<br />Code the middle tier<br />Test the middle tier<br />Write online help<br />Write the foo class<br />
    77. 77. Task Board<br />Visible<br />Editable<br />Update Daily<br />Own By team<br />
    78. 78. Product BackLog VS Sprint Backlog<br />Code the middle tier (8 hours)<br />Code the user interface (4)<br />Write test fixtures (4)<br />Code the foo class (6)<br />Update performance tests (4)<br />As a vacation planner, I want to see photos of the hotels.<br />
    79. 79. Burndown charts<br />Effort Left<br />Date<br />
    80. 80. Brundown Charts<br />Update daily, usually during the daily stand-up<br />Represent the amount of work remaining<br />Different approaches to create burndown charts<br />Estimated remaining time<br />Track done<br />
    81. 81. Tasks<br />Mon<br />Tues<br />Wed<br />Thur<br />Fri<br />4<br />8<br />12<br />7<br />10<br />16<br />11<br />16<br />8<br />Burndown charts<br />Code the user interface<br />8<br />Code the middle tier<br />16<br />Test the middle tier<br />8<br />50<br />Write online help<br />12<br />40<br />30<br />Hours<br />20<br />10<br />0<br />Mon<br />Tue<br />Wed<br />Thu<br />Fri<br />
    82. 82. Burndown charts<br />Possible over commitment<br />Possible Under commitment<br />Commitment achieved. Keep this velocity for next Sprint<br />
    83. 83. Roles<br />Ceremonies<br />Artifacts<br /><ul><li>Product owner
    84. 84. Scrum Master
    85. 85. Team
    86. 86. Sprint
    87. 87. Sprint planning
    88. 88. Sprint review
    89. 89. Sprint retrospective
    90. 90. Daily scrum meeting
    91. 91. Product backlog
    92. 92. Sprint backlog
    93. 93. Burndown charts</li></li></ul><li>Sprint goal<br />24 hours<br />Cancel<br />Gift wrap<br />Return<br />Coupons<br />Gift wrap<br />Coupons<br />Cancel<br />Sprint backlog<br />Return<br />Sprint<br />2-4 weeks<br />Potentially shippable<br />product increment<br />Product<br />backlog<br />Image available at<br />
    94. 94. Sprint<br />Sprint<br />2-4 weeks<br />Scrum projects make progress in a series of “sprints”<br />Analogous to Extreme Programming iterations<br />Typical duration is 2–4 weeks or a calendar month at most<br />A constant duration leads to a better rhythm<br />Product is designed, coded, and tested during the sprint<br />
    95. 95. Sprint<br />Change<br />Plan sprint durations around how long you can commit to keeping change out of the sprint<br />
    96. 96. Sprint Planning<br />Sprint backlog<br />Team selects items from the product backlog they can commit to completing<br />Sprint backlog is created<br />Tasks are identified and each is estimated (1-16 hours)<br />Collaboratively, not done alone by the Scrum Master<br />High-level design is considered<br />
    97. 97. Sprint prioritization<br />Sprint planning<br />Sprint<br />backlog<br /><ul><li>Analyze and evaluate product backlog
    98. 98. Select sprint goal
    99. 99. Decide how to achieve sprint goal (design)
    100. 100. Create sprint backlog (tasks) from product backlog items (user stories / features)
    101. 101. Estimate sprint backlog in hours</li></ul>Sprint Planning<br />Sprint goal<br />Sprint planning meeting<br />Team capacity<br />Product backlog<br />Business conditions<br />Current product<br />Techno-logy<br />
    102. 102. Daily Scrum meeting<br />Parameters<br />Daily<br />15-minutes<br />Stand-up<br />Not for problem solving<br />Whole world is invited<br />Only team members, ScrumMaster, product owner, can talk<br />Helps avoid other unnecessary meetings<br />
    103. 103. Daily scrum meeting<br />Only the team talks<br />Not to Scrum Master<br />No problem solving<br />Max 15 minutes<br />Standing up<br />1<br />2<br />3<br />What have you done yesterday?<br />What will be done today?<br />Is anything in your way?<br />
    104. 104. Sprint review <br />Team presents what it accomplished during the sprint<br />Typically takes the form of a demo of new features or underlying architecture<br />Informal<br />2-hour prep time rule<br />No slides<br />Whole team participates<br />Invite the world<br />
    105. 105. Sprint retrospective<br />Periodically take a look at what is and is not working<br />Typically 15–30 minutes<br />Done after every sprint<br />Whole team participates<br />ScrumMaster<br />Product owner<br />Team<br />Possibly customers and others<br />
    106. 106. Sprint retrospective<br />
    107. 107. Review<br />
    108. 108. 3 – 3 – 5 <br />Roles<br />Ceremonies<br />Artifacts<br /><ul><li>Product owner
    109. 109. Scrum Master
    110. 110. Team
    111. 111. Sprint
    112. 112. Sprint planning
    113. 113. Sprint review
    114. 114. Sprint retrospective
    115. 115. Daily scrum meeting
    116. 116. Product backlog
    117. 117. Sprint backlog
    118. 118. Burndown charts</li></li></ul><li>Scrum Process<br />ScrumMaster<br />Product Owner<br />Image available at<br />Team<br />
    119. 119. There’s no silver bullets<br />
    120. 120. Thank you<br />