Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Shayke's SCRUM @alphageeks 6


Published on

At the recent alphageeks 6 meetup, Shay Cohen is talking about his group's experience with implementing SCRUM.

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

Shayke's SCRUM @alphageeks 6

  1. 1. Scrum In Action<br />Shay Cohen<br />11/5/2010<br />
  2. 2. Agenda<br />The Pain Points<br />What is SCRUM ?<br />Scrum Flow<br />Roles<br />Planning a Sprint<br />Pillars & Principals<br />The Results<br />From hell to Heaven<br />Recommendation<br />
  3. 3. Worked very similar way to waterfall<br />Try define all at the beginning<br />Break the plan<br />Fix and delay as we go along<br />Months ahead<br />Every feature is P0<br />Low productivity due to missing / changing requirements<br />Low visibility during planning stage<br />Long release cycles – TTM<br />We establishing our RoB as we progress<br />A lot of noise during the development – DCRs, Integrations, Bugs<br />Poor WLB<br />The Pain Points <br />Areas for improvement:<br />Communication<br />Simplicity<br />Feedback<br />Courage<br />
  4. 4. SCRUM in 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.<br />The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features.<br />Every 5w anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.<br />
  5. 5. Scrum Flow<br />
  6. 6. Roles<br />Product Owner<br />PM<br />SCRUM Masters<br />Team Leaders<br /><ul><li>Represent the stakeholders
  7. 7. Owner the Product backlog
  8. 8. Owner the Sprint backlog
  9. 9. Responsible for the prioritization process
  10. 10. Approve removal of items during running sprint
  11. 11. Protect the Team and keep them focused on the tasks in hand
  12. 12. Manage the daily SCRUM meetings
  13. 13. Update the dev task progress</li></ul>Teams<br />Has the responsibility to deliver the product<br />
  14. 14. Planning a Sprint<br />Product Backlog<br />Iteration Backlog<br />User Stories<br />User Stories<br />Tasks (hours)<br />Commit!<br />1<br />1<br />1<br />Commit!<br />Can’t Commit!<br />
  15. 15. Planning a Sprint<br />Product Backlog<br />Iteration Backlog<br />User Stories<br />User Stories<br />Tasks (hours)<br />Commit!<br />1<br />1<br />1<br />Commit!<br />?<br />1<br />Commit!<br />
  16. 16. Sprint Vs. Release<br />Sprint<br />Fixed duration<br />Potentially deployable<br />Release<br />Fixed content<br />Content of one or more Sprints<br />Deployable<br />Requires stabilization period and ZBB<br />
  17. 17. Pillars & Principals<br />Planning take place before the sprint begin<br />We only plan what we know (well defined)<br />Each user story get unique priority<br />High priority items should be scheduled to the beginning of the sprint<br />We strive for HLD & STP before planning<br />All tests are automated (Unit, Component, E2E)<br />No test – no feature (E2E)<br />Sprint N-1<br />Planning N<br />Sprint N<br />Dev/Test<br />Dev/Test<br />Dev/Test<br />Dev/Test<br />Quality<br />Sprint N+1<br />Dev/Test<br />Planning N+1<br />Planning N+1<br />
  18. 18. Pillars & Principals<br />Last week is for quality and planning – no “new” code<br />No buffers – Every developer has a long tail of low priority user story<br />New backlog items shall not be added to a running sprint<br />Integrations are planned for beginning* of Sprint<br />Deployments ? Integrations ? Live system support ?<br />Sprint N-1<br />Planning N<br />Sprint N<br />Dev/Test<br />Dev/Test<br />Dev/Test<br />Dev/Test<br />Quality<br />Sprint N+1<br />Dev/Test<br />Planning N+1<br />Planning N+1<br />
  19. 19. Addressing Pain Points<br />
  20. 20. The Results I<br />
  21. 21. The Results II<br />
  22. 22. From hell to Heaven<br />The outcome<br />The “right” feature are in, Nice-to-have / future are out<br />Better TTM <br />Better Quality<br />Better transparency<br />Less status reports/emails<br />Less meetings<br />Well known & establish ROB<br />Developers have clear and quiet work plan and environment <br />Better WLB<br />
  23. 23. Recommendations<br />Organization<br />Management buy-in / sponsorship<br />All or nothing - PM/Test/Dev<br />Daily scrum, Scrum of Scrums, Daily war-room on quality week<br />Quality & Automation<br />Test automation<br />Smoke Tests on submit<br />Nightly builds with BVT<br />Weekly / bi-weekly FRS & Manual tests<br />Quality week<br />Quality gates<br />State of mind<br />Transparency & communication is the key<br />Constantly give/take feedback<br />Courage<br />