Scrum & Waterfall: Friend or Foe?
•Als PPTX, PDF herunterladen•
3 gefällt mir•2,496 views
How compatible is Scrum with Waterfall? We are experimenting with Scrum in a waterfall environmnet, what to do?
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (12)
Ähnlich wie Scrum & Waterfall: Friend or Foe?
Ähnlich wie Scrum & Waterfall: Friend or Foe? (20)
Mehr von Silvana Wasitova, Scrum & Agile Coach
Mehr von Silvana Wasitova, Scrum & Agile Coach (13)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Scrum & Waterfall: Friend or Foe?
- 1. Waterfall and Scrum: Friend or Foe? Service Knowledge Result Agile Tour Lausanne 18 November 2011 Silvana Wasitova, PMP, CSP
- 2. About me PMI Member since 1998 PMP 2002 President of PMI Silicon Valley, 2004 Scrum Practitioner 2005 Certified Scrum Master 2007 Scrum Coach & Trainer since 2009
- 3. At
- 5. 3 MONTHS Scrum vs. Waterfall: Time To Market Faster Time to Market Higher Quality Scrum Satisfied Customer Collaborative Spec Develop & QA Results-Oriented 6-10 MONTHS 9 weeks Waterfall 3 months Spec Develop & QA Updates 12 weeks 3-6 wks x wks y wks 6-10 months Sequential © Silvana Wasitova Process-Oriented
- 6. Delivering Business Value Scope Definition Specs Develop QA Regression Deploy Business Value Waterfall Scrum Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Time 6 © Itecor all rights reserved
- 7. 7 © Itecor all rights reserved
- 8. 8 © Itecor all rights reserved
- 9. Definition of Success Has Changed Functionality 85% respondents consider it more important to meet stakeholder needs, even if they changed Quality: 82% consider it more important to deliver high quality than delivering on time and within Money 70% consider best ROI more important than under budget Source: Software Development Projects Success, IBM, Scott Ambler, 2008 9 © Itecor all rights reserved
- 10. Why Scrum works 1. Close collaboration with client (or proxy) better product increased satisfaction 2. Transparency through daily check-ins early visibility of issues early resolution reduced risk 3. Increased ROI: delivering business value in small increments, more often 4. Eliminate waste, focus on highest priorities 5. Inspect, adapt, improve: in each iteration 10 © Itecor all rights reserved
- 11. Agile deals with Ziv’s Law • Specifications will never be fully understood Humphrey’s • The user will never be sure of what they want Law until they see the system in production (if then) Wegner’s • An interactive system can never be fully Lemma specified, nor can it ever be fully tested Langdon’s • Software evolves more rapidly as it approaches Lemma chaotic regions (without spilling into chaos) 11 © Itecor all rights reserved
- 12. QSM: Quality Software Management 2008 12 © Itecor all rights reserved
- 15. SURPRISE! Agile practices are aligned with PMBOK process groups: initiating, planning, executing, monitoring, controlling, closing In each iteration: Planning, executing, monitoring, controlling Manage scope, time, cost and quality
- 16. Agile & Waterfall - Comparison Source: Michelle Sliger, PMI Global Congress 2008
- 17. Agile & Waterfall - Comparison Source: Michelle Sliger, PMI Global Congress 2008
- 18. Agile & Waterfall - Comparison Source: Michelle Sliger, PMI Global Congress 2008
- 19. Agile & Waterfall - Comparison Source: Michelle Sliger, PMI Global Congress 2008
- 20. 20 © Itecor all rights reserved
- 22. Cone of Uncertainty PMBoK Estimation variances: Order of magnitude: +75% to -25% Budgetary estimate: +25% to -10% Definitive estimate: +10% to -5% Boehm, 1981
- 23. Decision Criteria: Scrum vs. Waterfall Criteria Scrum Candidate Waterfall Candidate What To Build or Iterate to clarify Both are known How to Build it direction / details Market or User Want Market/User input User/Market input Feedback and to improve usability not needed Involvement Time to Market vs. Flexible about Scope Flexible about Time Feature Content
- 24. Friend or Foe?
- 25. Good Neighbour
- 26. Scrum Adoption at Yahoo 2004: VP of Product Development authorized experiment with scrum 2005: Hired Senior Director of Agile Development 2008 status: 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 those first three years, 15-20% of people consistently DID NOT like Scrum http://agilesoftwaredevelopment.com/blog/artem/lessons-yahoos-scrum-adoption 26 © Itecor all rights reserved
- 27. Salesforce.com - 2007 Down to 1 release/yr Scrum adoption: 3 months Results: 60+ Critical features delivered in < 9 months “Idea to Release” avg. rate: 2.2 quarters 70% of “Top 10 Ideas” on track for delivery in 2007 27 http://www.slideshare.net/sgreene/salesforcecom-agile-transformation-agile-2007-conference
- 28. Barriers to Adoption http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf 28 © Itecor all rights reserved
- 29. MINDSET CHANGE 29 © Itecor all rights reserved
- 30. Visionary & Champion Christopher Colombus
- 31. Sponsor Queen Isabelle
- 32. Translation Key Rosetta Stone
- 33. Trainer & Coach Coach Extraordinaire
- 34. Agile Champions http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf
- 35. Strategy: A.D.A.P.T. A • AWARENESS that the current approach is not working D • DESIRE to change A • ABILITY to work in agile manner P • PROMOTE early success, build momentum T • TRANSFER impact to other parts of organization, to stick Mike Cohn, MountainGoat Software 35 © Itecor all rights reserved
- 36. Eight Steps to a Large Scale Change Increase urgency Build the Guiding Team Get the Vision Right Communicate for Buy-In Empower Action Create Short-term Wins Don’t Let Up Make Change Stick 36 © Itecor all rights reserved
- 37. What Works
- 40. Build Organizational Support Top Down Bottom Up In all directions Horizontal at the same time
- 41. Teamwork 41 © Itecor all rights reserved
- 42. Align Incentives
- 43. Inspect, Adapt Thomas A. Edison 43 © Itecor all rights reserved
- 44. COURAGE
- 45. 45
- 46. Silvana Wasitova, PMP, CSM, CSP Itecor.com Vevey, Switzerland s.wasitova@itecor.com +41 79 558 05 09 slideshare.com/wasitova 46
- 47. References Michelle Sliger, PMI Global Congress 2008 – http://www.slideshare.net/VersionOne/agile-project-management-for-pmps http://www.infoq.com/presentations/Agile-in-the-Waterfall-Enterprise-Michele-Sliger VersionOne Survery 2009 - http://www.versionone.com/pdf/2009_State_of_Agile_Development_Survey_Results.pdf VersionOne Survery 2008 - http://www.versionone.com/pdf/3rdAnnualStateOfAgile_FullDataReport.pdf Gartner - http://analytical-mind.com/2010/02/25/gartners-the-current-state-of-agile-method-adoption/ Forrester - http://www.forrester.com/rb/Research/agile_development_mainstream_adoption_has_changed_agility/q/id/56100/t/2 Scott Ambler, Software Development Projects Success, 2008 Barry Boehm, “Cone of Uncertainty”, 1981 Mike Cohn , MountainGoat Software, “ADAPT” concept John Kotter, “Leading Change” References for Distributed Teams: Elizabeth Woodward, IBM – “A Practical Guide to Distributed Scrum“ Video Interview: http://itknowledgeexchange.techtarget.com/software-quality/elizabeth-woodward-face-to-face- communication-is-biggest-challenge-with-distributed-scrum/ Guido Schoonheim & Jeff Sutherland , Aug 2010 – “Mind the Gap! Principles of Hyperproductive fully Distributed Scrum” Jeff Sutherland - SirsiDynix – 2007, Agile with Outsourced Teams - http://jeffsutherland.com/SutherlandFullyDistributedScrumSirsiDynixHICSS2007 Jeff Sutherland - Xebia - Agile 2008 - http://jeffsutherland.com/SutherlandFullyDistributedScrumXebiaAgile2008.pdf Craig Larman & Bas Vodde, Scaling Lean & Agile Development: Successful Large, Multisite & Offshore Products with Large- Scale Scrum” Salesforce - Kerievsky & Dourambeis, Large Scale & Distributed Agile http://agile2010.agilealliance.org/distributed 47
- 48. 48 © Itecor all rights reserved
Hinweis der Redaktion
- Stay flexible by reducing obstacles to changeChange is your best friend. The more expensive it is to make a change, the less likely you'll make it. And if your competitors can change faster than you, you're at a huge disadvantage. If change gets too expensive, you're dead.EmergenceEmergence is one of the founding principles of agility, and is the closest one to pure magic. Emergent properties aren't designed or built in, they simply happen as a dynamic result of the rest of the system. "Emergence" comes from middle 17th century Latin in the sense of an "unforeseen occurrence." You can't plan for it or schedule it, but you can cultivate an environment where you can let it happen and benefit from it.A classic example of emergence lies in the flocking behavior of birds. A computer simulation can use as few as three simple rules (along the lines of "don't run into each other") and suddenly you get very complex behavior as the flock wends and wafts its way gracefully through the sky, reforming around obstacles, and so on. None of this advanced behavior (such as reforming the same shape around an obstacle) is specified by the rules; it emerges from the dynamics of the system.Simple rules, as with the birds simulation, lead to complex behavior. Complex rules, as with the tax law in most countries, lead to stupid behavior.Many common software development practices have the unfortunate side effect of eliminating any chance for emergent behavior. Most attempts at optimization — tying something down very explicitly — reduces the breadth and scope of interactions and relationships, which is the very source of emergence. In the flocking birds example, as with a well-designed system, it's the interactions and relationships that create the interesting behavior.The harder we tighten things down, the less room there is for a creative, emergent solution. Whether it's locking down requirements before they are well understood or prematurely optimizing code, or inventing complex navigation and workflow scenarios before letting end users play with the system, the result is the same: an overly complicated, stupid system instead of a clean, elegant system that harnesses emergence.Keep it small. Keep it simple. Let it happen.—Andrew Hunt, The Pragmatic Programmers
- PMBOK Processes
- The Cone of Uncertainty – ref. http://en.wikipedia.org/wiki/Cone_of_Uncertaintyhttp://www.construx.com/Page.aspx?cid=1648early project estimates are wildly inaccurate: Estimates (e.g. on duration, costs or quality) are inherently very vague at the beginning of a project Estimates and project plans based on estimations need to be redone on a regular basis Uncertainties can be built into estimates and should be visible in project plans Assumptions that later prove to be mistake are major factors in uncertainty Early in a project, specific details of the nature of the software to be built, details of specific requirements, details of the solution, project plan, staffing, and other project variables are unclear. The variability in these factors contributes variability to project estimates -- an accurate estimate of a variable phenomenon must include the variability in the phenomenon itself. As these sources of variabiility are further investigated and pinned down, the variability in the project diminishes, and so the variability in the project estimates can also diminish. This phenomenon is known as the “Cone of Uncertainty” which is illustrated in the following figure. As the figure suggests, significant narrowing of the Cone occur during the first 20-30% of the total calendar time for the project. Effective delivery of projects on time and on budget requires the application of a clear risk management approach throughout the whole project life cycle. The key learning from this approach is that any project estimate is meaningless without an accompanying confidence level. Applying this principle allows the management of both dimensions in project estimation, which in turn improves the identification and mitigation of risks throughout the project life cycle.
- BIGGER THAN ANY OF US can do aloneWhat must we do together that is bigger then any of us, requires all of us, and none of us can claim individual victory until it is done?Assume personal responsibility for the success of the team.The more members feel a sense of ownership for the entire team, the more likely good team-building things will happen.TOP Step1: Build shared clarity about the task (and keep pointing to it as the reason for the team). This is the single greatest lever for team-building. Feeling a sense of positive interdependence (i.e., you moving your work forward helps me accomplish mine) or “being in the same boat together” drives a natural shift in behavior toward helpfulness and trust.
- Your thoughts & experiencesIs it easy?We’ve heard it all: black, white, and shades of gray in between.many Agile principles aren’t intuitive or are counter to traditional management approaches. Some of these initially counter-intuitive principles:Starting more stuff faster means you will finish more stuff later. Striving for perfect definition up front is going to slow down delivery. Don’t build everything that might ever be needed right now – only build what you will need today. More testing speeds you up. Changing Mental Models creates new possibilities and allows us to make better decisions. We allow the results to influence our Mental Model and not just the next decision. When learning influences our Mental Model we call this Double Loop Learning.
- To collaborate across silos
- To collaborate across silos
- Change Management expense http://drdobbs.com/tools/229401451 Gartner estimates that worldwide IT spending last year was $1.6 trillion, with IT services at $816 billion as the largest component of that figure. Typically, 3% to 10% of the IT services budget allocations can be associated with process improvement initiatives, so we can estimate that $17 billion in spending is doomed to not deliver the intended results (70% of $24.5 billion). And that doesn't include opportunity costs associated with failed process improvement and costs associated with lost productivity during the change. Gartner estimates that worldwide IT spending last year was $1.6 trillion, with IT services at $816 billion as the largest component of that figure. Typically, 3% to 10% of the IT services budget allocations can be associated with process improvement initiatives, so we can estimate that $17 billion in spending is doomed to not deliver the intended results (70% of $24.5 billion). And that doesn't include opportunity costs associated with failed process improvement and costs associated with lost productivity during the change. A Pragmatic ApproachOne approach, which I call SDLC 3.0, provides a pragmatic, experience-based approach for integrating the fragmented methodology landscape by using practices that are methodology agnostic. It focuses on yielding a useful, context-specific set of standard work advice for real product development. It also integrates the software development part of IT with the broader enterprise and functions such as enterprise architecture, IT service management, and project and portfolio management. Using lean as the overarching set of principles, SDLC 3.0 starts with the customer and ends with the accrual of value within IT operations. This focus makes sure that small groups don't try to optimize only their piece of the process, based only on what they know about their roles. Rather, a coherent big-picture view enables traditionally siloed communities to constructively participate rather than get bogged down in in-fighting.
- http://www.microsoft.com/downloads/details.aspx?familyid=AE7E07E8-0872-47C4-B1E7-2C1DE7FACF96