Your SlideShare is downloading. ×
Getting Started with Scrum
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Getting Started with Scrum

471
views

Published on

How to get started with Scrum: three case studies. Presented at Project Zone, Frankfurt, April 2014

How to get started with Scrum: three case studies. Presented at Project Zone, Frankfurt, April 2014

Published in: Software, Technology, Sports

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
471
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
29
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Getting Started with Scrum Silvana Wasitova, CSM, CSP, PMP, PMI-ACP Frankfurt, April 2014
  • 2. Managed projects in 12 countries, lived in 7 2002: PMP 2004: President of PMI Silicon Valley 2005: started practicing Scrum 2009: Scrum Coach & Trainer 2011: PMI-ACP Silvana Wasitova, PMP, ACP, CSM, CSP
  • 3. Rolland Garros February Yahoo-Eurosport: 2008 Event Schedule January April May JuneMarch Rugby 6 Nations Wimbledon TDF Euro Paris-Dakar Tour de France Moto GP Golf, Athletics, Cycling Basketball Boxing Horse Racing Hockey, etc FOOT: Olympic Games qualifiers World Cup qualifiers 30-Apr-14 5
  • 4. Scrum Adoption at Source: Gabrielle Benefield http://agilesoftwaredevelopment.com/blog/artem/lessons-yahoos-scrum-adoption • 2004: One person experimented with scrum • 2005: VP of Product Development hired Senior Director of Agile Development • 2008: 3 coaches, each coaching approx. 10 scrum teams/year 200 scrum teams world wide, total approx. 1500+ employees • Results in 2008: Average Team Velocity increase estimated at +35% / year, in some cases 300% - 400% Development cost reduction of over USD 1 million / year ROI on transition and trainings about 100% in first year • Note: In first three years, 15-20% of people consistently DID NOT like Scrum 6
  • 5. Everyone wants to change the world, but no one wants to change themselves. – Leo Tolstoy
  • 6. © Silvana Wasitova Scrum vs. Waterfall: Time To Market Develop & QASpec Develop & QA Spec Scrum Waterfall 12 weeks 3-6 wks y wks 9 weeks 3 months 6-10 months Collaborative Results-Oriented 3 MONTHS x wks Updates Sequential Process-Oriented 6-10 MONTHS  Faster Time to Market  Higher Quality  Satisfied Customer
  • 7. Why Scrum works: 1. Close collaboration with Customer 2. Transparency through daily reviews → risk reduction 3. LEAN ‘flow’ → frequent delivery of business value 4. Eliminate waste, focus on highest priorities 5. Inspect, adapt, improve - in each iteration
  • 8. Scrum Adoption at G IT HQ • 2010: One project experimented with scrum • 2012: 42 projects with Scrum, expected another 12 3 coaches, 60 trained ScrumMasters, 10 trained Product Owners 700+ people trained in “Scrum Basics” One division: We want Scrum Only, no more waterfall • Results in 2012: Better products Better quality Increased customer satisfaction ROI on transition and trainings about 100% in first year Note: Friction with budget-allocation & bonus-calculation models
  • 9. from Shingo's “Seven Wastes of Manufacturing” 7 Wastes of Software Development Partially Done Work (In-Process Inventory) Defects (Defects) Relearning (Extra Processing) Extra Features (Over-Production) Handoffs (Transportation) Delays (Waiting) 1 2 3 4 5 6 7 Every bit of code that is there and not needed creates complexity that will plague the code base for the rest of its lifeTask Switching (Motion) Ref: Implementing Lean Software Development: From Concept to Cash Mary Poppendieck
  • 10. http://www.agilemanifesto.org
  • 11. Waterfall, Agile and Scrum: Characteristics When is a project a “Scrum Project” and when is it not? 30-Apr-14 13 Waterfall Agile : Iterative Development Kanban DSDM Upfront, Detailed Emergent Design Linear hand-offs: Dev then QA Cross-functional & collaborative: Dev & QA Formal process, implemented at end Welcomed, prioritized vs. backlog At beginning and at delivery Throughout cycle Scrum • Daily “standup” status checks ≤ 15mins • Delivery rhythm in iterations (Sprints) • Demo & Retrospective at end of ea. Sprint  Continuous Improvement XP: eXtreme Programming • Automated Tests • Pair Programming • Automated / Continuous Builds • TDD: Test-Driven Development • Continuous Deployment Teamwork Change Requests Customer / User Involvement Specifications Scrum is the most popular Agile method: 74% of Agile practitioners (2009)
  • 12. Adapt to changing requirements throughout dev. cycle Continuous improvement via Retrospectives Early product delivery Transparency: daily standup Stress collaboration between developers and customers Strip-off non-essential activities & artifacts Regular reviews with Client/Product Owner Agile Philosophy 1 2 3 4 5 6 7
  • 13. • Specifications will never be fully understoodZiv’s Law: • The user will never be sure of what they want until they see the system in production (if then) Humphrey’s Law: • An interactive system can never be fully specified, nor can it ever be fully tested Wegner’s Lemma: • Software evolves more rapidly as it approaches chaotic regions (without spilling into chaos) Langdon’s Lemma: Agile deals with:
  • 14. Scrum Adoption Steps  Identify Product Owner, and Product to build  Articulate Product Vision and Goals  Explore User Stories  Construct a Product Backlog  Identify Scrum Master, Team  Construct a Sprint Backlog  Agree on “Definition of Done”  Agree on Sprint logistics  Sprint!  Inspect and Adapt
  • 15. Mechanics of Sprint Planning Activity Owner Timeframe Product Backlog (PB) grooming & prioritization Product Owner (PO) + others as needed Before Sprint Start Sprint Planning: 1. Take top priorities of PB 2. Break-down PB items into tasks 3. Estimate effort 4. Commit to Sprint Content Product Owner (PO) + Scrum Team + Scrum Master (+ others as needed) At Sprint Start Sprint Execution, feature development Scrum Team, Scrum Master, PO During Sprint Acceptance Testing of developed features Product Owner During Sprint, as developed Demonstration of Sprint Results Team / PO; Client/Users, Stakeholders At Sprint End Retrospective: what worked well, what to improve Scrum Team, Scrum Master, PO At Sprint End 17
  • 16. Example - Release Plan – initial version 30-Apr-14 Sprint 1 Sprint 6Sprint 2 Sprint 5Sprint 4Sprint 3 Mega Menu Top Nav Bottom Nav Left Nav version People Picker VSTTop Right Nav Test Env’t Left Nav Global Nav (Toolbar) Bottom Nav Bread- crumbs Authoring, Content Mgmt Search Portal Integration Wizzard Comms Panel Part 1 Comms Panel Part 3 Comms Panel Part 2 MAT News Rollup Ongoing activities: update taxonomy VST Feedback MAT Feedback Sprint 7 Prep for Cutover Planned Go Live Actual Go Live Sprint 8
  • 17. User Story Map Required Important Optional Essential “Backbone and skeleton” Identify the “Minimal viable product”
  • 18. User Story Map 20 http://www.agileproductdesign.com/blog/the_new_backlog.html
  • 19. Continuous Evolution of Product Backlog 21 Initial R 1 R 2 R 3 Ready R 3 S 1 S 2 S 3 S 4 R 2 Refined R 1 R 2 R 3 End of S1 R 3 S 2 S 3 S 4 R 2
  • 20. Agile Success Factors @  Commitment from Management & Execs  Trainings: Scrum Master, PO, Team members  Culture of learning - apply retrospective findings  Respect teams to be self-organizing  Agile Coach at each location
  • 21. Scrum of Scrums (15 mins)
  • 22. Eight Steps to a Large Scale Change John Kotter: Leading Change 1. Increase urgency 2. Build the Guiding Team 3. Get the Vision Right 4. Communicate for Buy-In 5. Empower Action 6. Create Short-term Wins 7. Don’t Let Up 8. Make Change Stick
  • 23. Why Agile Adoptions Fail 1. Ineffective use of the retrospective 2. Inability to get everyone in the planning meetings 3. Failure to pay attention to the infrastructure required 4. Bad ScrumMasters 5. PO Consistently Unavailable / too many owners who disagree 6. Reverting to Form 7. Only "Checkbook Commitments" from Executive Management 8. Teams Lacking Authority and Decision-Making Ability 9. Not Having an Onsite Evangelist for Remote Locations 10.A Culture that Does Not Support Learning 11.Embracing denial instead of the Brutal Truth Source: Jean Tabaka http://www.infoq.com/news/2007/09/why-do-agile-adoptions-fail
  • 24. 26© Itecor all rights reserved Align Incentives
  • 25. Appreciate
  • 26. TRUST
  • 27. COLLABORATE
  • 28. http://www.flickr.com/photos/psmithy/ PURPOSE
  • 29. How much do you trust each other?RESPECT
  • 30. Silvana Wasitova, CSM, CSP Lausanne, Switzerland wasitova@yahoo.com slideshare.com/wasitova

×