View stunning SlideShares in full-screen with the new iOS app!Introducing SlideShare for AndroidExplore all your favorite topics in the SlideShare appGet the SlideShare app to Save for Later — even offline
View stunning SlideShares in full-screen with the new Android app!View stunning SlideShares in full-screen with the new iOS app!
Agenda The Pain Points What is SCRUM ? Scrum Flow Roles Planning a Sprint Pillars & Principals The Results From hell to Heaven Recommendation
Worked very similar way to waterfall Try define all at the beginning Break the plan Fix and delay as we go along Months ahead Every feature is P0 Low productivity due to missing / changing requirements Low visibility during planning stage Long release cycles – TTM We establishing our RoB as we progress A lot of noise during the development – DCRs, Integrations, Bugs Poor WLB The Pain Points Areas for improvement: Communication Simplicity Feedback Courage
SCRUM in 100 words Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time. It allows us to rapidly and repeatedly inspect actual working software. The business sets the priorities. Teams self-organize to determine the best way to deliver the highest priority features. Every 5w anyone can see real working software and decide to release it as is or continue to enhance it for another sprint.
Teams Has the responsibility to deliver the product
Planning a Sprint Product Backlog Iteration Backlog User Stories User Stories Tasks (hours) Commit! 1 1 1 Commit! Can’t Commit!
Planning a Sprint Product Backlog Iteration Backlog User Stories User Stories Tasks (hours) Commit! 1 1 1 Commit! ? 1 Commit!
Sprint Vs. Release Sprint Fixed duration Potentially deployable Release Fixed content Content of one or more Sprints Deployable Requires stabilization period and ZBB
Pillars & Principals Planning take place before the sprint begin We only plan what we know (well defined) Each user story get unique priority High priority items should be scheduled to the beginning of the sprint We strive for HLD & STP before planning All tests are automated (Unit, Component, E2E) No test – no feature (E2E) Sprint N-1 Planning N Sprint N Dev/Test Dev/Test Dev/Test Dev/Test Quality Sprint N+1 Dev/Test Planning N+1 Planning N+1
Pillars & Principals Last week is for quality and planning – no “new” code No buffers – Every developer has a long tail of low priority user story New backlog items shall not be added to a running sprint Integrations are planned for beginning* of Sprint Deployments ? Integrations ? Live system support ? Sprint N-1 Planning N Sprint N Dev/Test Dev/Test Dev/Test Dev/Test Quality Sprint N+1 Dev/Test Planning N+1 Planning N+1
From hell to Heaven The outcome The “right” feature are in, Nice-to-have / future are out Better TTM Better Quality Better transparency Less status reports/emails Less meetings Well known & establish ROB Developers have clear and quiet work plan and environment Better WLB
Recommendations Organization Management buy-in / sponsorship All or nothing - PM/Test/Dev Daily scrum, Scrum of Scrums, Daily war-room on quality week Quality & Automation Test automation Smoke Tests on submit Nightly builds with BVT Weekly / bi-weekly FRS & Manual tests Quality week Quality gates State of mind Transparency & communication is the key Constantly give/take feedback Courage