PMBoK and Scrum: can we be friends?
•
38 likes•12,771 views
PMBoK and Scrum: can we be friends? -Scrum Day Asia Bandung, Indonesia, 24 Nov 2012
Recommended
Recommended
More Related Content
What's hot
What's hot (20)
Similar to PMBoK and Scrum: can we be friends?
Similar to PMBoK and Scrum: can we be friends? (20)
More from Silvana Wasitova, Scrum & Agile Coach
More from Silvana Wasitova, Scrum & Agile Coach (20)
Recently uploaded
Recently uploaded (20)
PMBoK and Scrum: can we be friends?
- 1. PMBOK and Scrum: Can we live together, happily ever after? Silvana Wasitova, PMP, CSM, CSP, ACP Scrum Day Asia Bandung, 24 November 2012
- 2. About me Waterfall 2 Scrum
- 3. 3
- 4. A Little bit of history…. 4
- 5. History of PMBOK • 1969: PMI established, foremost advocate for the project management profession • 1987: First PMBOK Established a standard and a lexicon Introduced formal planning & control 5
- 6. History of “Waterfall” • Waterfall Model – Originated in manufacturing and construction industries – Highly structured physical environments => after-the-fact changes are prohibitively costly • 1970: Winston Royce article – Showed waterfall as an example of a flawed, non-working model 6
- 7. Winston Royce’s “Grandiose” Model “Single Pass” phased model to cope with US DoD regulatory requirements “I believe in this concept, but the implementation is risky and invites failure.” Winston W. Royce, “Managing the development of large software systems”, Aug 1970 7
- 8. Winston Royce’s “Problem” Model Problem: Testing phase, at the end of Development cycle, is the first time the integrated components are “experienced”. Failure may require a major redesign, or modifying the requirements. Can expect up to 100% schedule and/or cost overrun. 8
- 9. Winston Royce’s Recommendation Iterations between phases, hopefully confined to successive steps 9
- 10. History of Scrum 1993 – Jeff Sutherland @ Easel Corporation • Vertical-licing • January 1994: first Scrum, self-organized team, half- day planning, Monthly Demo to the CEO • February: added “daily Scrums” • March: pairing, “swarming” on top priorities 1995 – Scrum paper at OOPSLA, Ken Schwaber and Jeff Sutherland 10
- 11. The Agile Manifesto - 2001 We are uncovering better ways of developing software. Through this work we have come to value: • Working software over comprehensive documentation • Individuals and interactions over processes and tools • Customer collaboration over contract negotiation • Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 11 11
- 12. PMBOK and Scrum: Similarities • Deliver the right thing Scope (on time, on budget) Time Budget 12
- 13. The biggest danger in Project and Product Management: Building the wrong thing! Page # 13
- 14. PMBOK and Scrum: Similarities • Deliver the right thing • Communicate, communicate, communicate 14
- 16. • Collaborate with clients and users • Many mistakes are avoidable 16
- 17. PMBOK and Scrum: Similarities • Deliver the right thing • Communicate, communicate, communicate • Progressive elaboration 17
- 18. Continuous Evolution of Product Backlog Initial Refined Ready End of S1 S S 1 2 R R S S 1 1 2 3 S S 3 4 S 4 R R R 2 2 2 R 2 R R R 3 R 3 3 3
- 19. PMBOK and Scrum: Similarities • Deliver the right thing • Communicate, communicate, communicate • Progressive elaboration • Cyclical: Plan, Execute, Monitor & Control 19
- 20. 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 20
- 22. PMBOK and Scrum: Differences • Agile Focus: Minimize Waste (“Muda” in Lean) • “Heavy” vs. “Light” process, umpteen checklists 22
- 24. Scrum Framework: Summary • Product Owner • Product Backlog • Product Planning • Team • Sprint Backlog • Sprint Planning • Scrum Master • Potentially • Daily Standup (Scrum) Shippable Product • Sprint Review • Burn-down Chart • Sprint Retrospective 24
- 25. PMBOK and Scrum: Differences • Agile Focus: Minimize Waste (“Muda” in Lean) • “Heavy” vs. “Light” process, umpteen checklists • Maximize “work not done” 25
- 26. 64% implemented features are rarely or never used Focusing on customer needs ensures: the right features are built Sometimes Rarely not wasting effort (and resources) on 16% 19% Often features that are not needed 13% Always 7% Never While the figures may vary by 45% company, principle remains: Only build the features that the client/users need Ref: Jim Johnson, Chairman of Standish Group, quoted in 2006 in: http://www.infoq.com/articles/Interview-Johnson-Standish-CHAOS Sample: government and commercial organizations, no vendors, suppliers or consultants 26
- 27. PMBOK and Scrum: Differences • Agile Focus: Minimize Waste (“Muda” in Lean) • “Heavy” vs. “Light” process, umpteen checklists • Maximize “work not done” • BDUF vs. build in increments, vertical slices • Adaptability! • Fail fast, inspect and adapt, keep learning -> creates a “learning organization” 27
- 28. Waterfall, Agile and Scrum: Characteristics Waterfall Agile : Iterative Development Scrum Specifications Upfront, Detailed Emergent Design • Daily “standup” status checks ≤ 15mins • Delivery rhythm in iterations (Sprints) • Demo & Retrospective at end of ea. Sprint Linear hand-offs: Cross-functional & Continuous Improvement Teamwork Dev then QA collaborative: Dev & QA XP: eXtreme Change Formal process, Welcomed, Requests implemented at end prioritized vs. backlog Programming • Automated Tests • Pair Programming Customer / User At beginning and • Automated / Continuous Builds • TDD: Test-Driven Development Involvement at delivery Throughout cycle • Continuous Deployment Scrum is the most popular Agile method: RUP DSDM 74% of Agile practitioners (2009) 28 28
- 29. Scrum vs. Waterfall Waterfall Scrum Approach Freezes scope, estimates schedule Freezes schedule, estimates scope Client Involvement At beginning and end Frequent collaboration Scope Build “everything in the specs” Build what client really needs, by priority Design Design all features up front Emergent design of few features per iteration Development Linear path across phases Iterative, incorporate learning Delivery “Big Bang” at end Frequent, small increments Continuous functional & unit testing inside Testing Separate phase, after development iterations Cost of Change High Low Requirements Defined up front, rigid Allow changes up to “last responsible moment” Documentation Up front and exhaustive Document only what is built, as needed © Itecor all rights reserved 29 Team Communication At phase-handoffs Continuous, cross-functional 29
- 30. Project Management: Agile vs. Waterfall approach Waterfall Agile Work Assignment Project Manager Self-organizing team Responsibilities Delineated Shared Task Ownership Separated Shared: all for one, one for all Status reports By Project Manager Transparency, shared knowledge Requirements Defined up-front, signed-of High level, detailed in collaborations Plans Detailed plans upfront Evolutionary planning Changes Not welcome Allow changes up to “last responsible moment”, prioritized 30
- 31. Agile deals with Ziv’s Law: • Specifications will never be fully understood • The user will never be sure of what they want Humphrey’s Law: until they see the system in production (if then) Wegner’s • An interactive system can never be fully specified, Lemma: nor can it ever be fully tested Langdon’s • Software evolves more rapidly as it approaches Lemma: chaotic regions (without spilling into chaos) Wicked Problems, Righteous Solutions, Peter deGrace, Leslie Hulet 31
- 32. Agile Solutions to Common Problems 32
- 33. Lean, Agile, Scrum: How they relate Two things in common: Eliminate Waste & Increase Customer Value Waste: anything which does not advance the process, or add value Value: any action or process that a customer would be willing to pay for Lean Agile Scrum • A production practice that •Agile is a group of methodologies •Scrum is the most popular Agile considers the expenditure of based on iterative and incremental methodology used in software resources for any goal other delivery, where requirements and development. than the creation of value for solutions evolve through collaboration the end-customer to be between clients and self-organizing, •Scrum emphasizes iterative wasteful, and thus a target for cross-functional teams. approach to building elimination. incremental business value. •Agile practices include: • Agile practices are rooted in lean Scrum, Kanban, XP (eXtreme philosophy. Programming), TDD (Test Driven Development), RUP (Rational Unified Process from IBM). 33
- 34. 3 MONTHS Scrum vs. Waterfall: Time To Market Faster Time to Market Higher Quality Satisfied Customer Scrum Collaborative Develop & QA Results-Oriented Spec 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 Process-Oriented © Silvana Wasitova
- 35. Yahoo-Eurosport: 2008 Event Schedule TDF Euro Paris-Dakar Tour de France January February March April May June Rugby 6 Nations Rolland Garros Wimbledon FOOT: Moto GP Boxing Olympic Games qualifiers Golf, Athletics, Cycling Horse Racing World Cup qualifiers Basketball Hockey, etc 35 35 25-Nov-12
- 37. PMBOK Strengths Process oriented Clear project kickoff & administrative initiation Enumeration of stakeholders, formalized communication plan More explicitly calls for cost management Risk management formalized: identification, qualitative and quantitative analysis, response planning 37
- 38. Agile Strengths Empowered, self-organizing team Collaboration, cross-fertilization, disciplined, shared responsibilities & commitments Welcomes adjustments and learnings Produces better results Risk mitigation practices Smaller units of work more accurate Frequent checks fewer surprises & delays Welcomes voice of the customer Build the right thing 38
- 39. Use the right tool for the job 39
- 40. 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 40
- 41. Scrum Process Key Practices Self-directed; self-organizing teams (preferably co-located) 15 minute daily stand up meeting with 3 special questions 30-calendar day iterations Iterative Adaptive planning Stakeholder/Customer Involvement Team measures progress daily Each iteration delivers tested, fully-functional software for demonstration Iterative Retrospective Process Always 30-days from potential production release
- 42. PMI Agile Certification • Wonderful development, recognition of real need • Available May 2011 • Like PMP, requires experience: o 1,500 hours working in Agile project teams (any role) or in Agile methodologies in last 2 yrs o 2,000 hours general PM experience in last 5 yrs (or PMP) o 21 hours Training in Agile project management topics • More info: http://www.pmi.org/en/Agile/ Agile-Certification-Eligibility-Requirements.aspx 42
- 43. Stay relevant 43
- 44. 44 It does not have to hurt
- 45. It’s a brave new world 45 out there
- 46. PMBOK and Scrum: Can we live together, happily ever after? Not a marriage, but: Yes - Good, respectful, neighbours 46
- 47. PMBOK and PMP: why keep them? • Large Enterprises often have PMBoK-based practices in place, PMOs • It helps to “speak the language”, to do the common mapping 47
- 48. Silvana Wasitova, PMP, CSM, CSP, ACP Lausanne, Switzerland wasitova@yahoo.com +41 79 558 05 09 slideshare.com/wasitova 48
- 49. Skype Beta Program Unparalleled Global Beta Testing Program Unique experiences from world-leading SW Company Access to Skype information system Various incentive programs for beta testers
- 50. Skype Beta Program: Registration Pre-requisites: • Intermediate level of English (Read & Write) + Native Language • Skype experience at least 1 year • Curiosity for IT technology Contact : Beom Soo Park, Program Manager for APAC beomsoo.park@skype.net
- 51. 51
- 52. References • Jeff Sutherland’s blog - http://scrum.jeffsutherland.com/ • “The New New Product Development Game” Takeuchi and Nonaka. Harvard Business Review, January 1986 • “The PMBOK and Agile: Friends or Foes?”, Mary Gerush and Dave West, Forrester 2009 • “Five Myths of Agile Development”, Robert Holler, VersionOne, 2006 • Winston W. Royce, “Managing the development of large software systems”, Aug 1970 http://www.valucon.de/documents/managing_softwareprojects.pdf • “Diagnosing and Changing Organizational Culture”, Cameron and Quinn, 2006 • “Living with Complexity”, Norman, Donald (2011), Cambridge, MA: MIT Press • “Leading Change”, John Kotter • http://www.stickyminds.com/pop_print.asp?ObjectId=10365&ObjectType=COL • “Project Management Body of Knowledge” (PMBOK), 2004 • http://agile101.net/2009/08/18/agile-estimation-and-the-cone-of-uncertainty/ • http://www.mountaingoatsoftware.com • http://www.agilealliance.org • http://www.c-spin.net/2009/cspin20090204AgileTransformationAtBorland.pdf • Primavera – PMISV presentation by Bob Schatz, Primavera VP of Development, 2005 • Why Agile Works http://www.slideshare.net/yourpmpartner/agile-secrets-revealed-whitepaper 52
- 53. Key Success Factors Sufficient Motivation to change (Pain) Team Rooms Feature Budgeting Build Process Town Hall Project Meetings Project Manager role transition Information Radiators No OT / Weekend work Test-Driven Development Rotating “ScrumMaster” Responsibilities Best Team Performance Awards Team-based bonus component Sprint Defect Limits Customer Webex Sprint Reviews Commitment to Learning! project success = business success TM
- 54. Scrum Adoption at Ref: http://agilesoftwaredevelopment.com/blog/artem/lessons-yahoos-scrum-adoption VP of Product Development experimented with scrum in 2004 Senior§ Director of Agile Development started in 2005 In 2008: 3 coaches, each coaching approx. 10 scrum teams/year 200 scrum teams world wide, of about 1500+ employees Results in 2008: Average Team Velocity increase estimated at +35% / year, in some cases 300% - 400% Development cost reduction over USD 1 million / year ROI on transition and trainings about 100% in first year Note: 15-20% of people consistently DID NOT like Scrum 54
Editor's Notes
- Winston W. Royce,Managing the development of large software systemsProc. IEEE WESCON, Aug 1970Royce developed the phased delivery model to cope with regulatory requirements set out in the US DoD STD-2167 document, which was so byzantine and bureaucratic that the waterfall was the only way to cope with it;
- http://www.techdarkside.com/is-there-really-any-rigor-in-waterfallIt is sad that software development philosophies and practices developed in a world of government regulation, punch cards, and very expensive computer time still have such a strong a hold on today’s commercial software development.Ben Simohttp://QuestioningSoftware.com
- Winston W. Royce,Managing the development of large software systemsProc. IEEE WESCON, Aug 1970Royce’s Son:http://usability.typepad.com/confusability/2006/02/index.html
- Reduce hierarchy
- Can be on time, on budget, on scope, But still built the wrong product that no one needs.
- Progressive elaboration
- Discipline:Structured approach,Plan aheadmodel itself progresses linearly through discrete, easily understandable and explainable phases and thus is easy to understand; it also provides easily markable milestones in the development process.Steve McConnell, in Code Complete, (a book that criticizes widespread use of the waterfall model) refers to design as a "wicked problem"—a problem whose requirements and limitations cannot be entirely known before completion. The implication of this is that it is impossible to perfect one phase of software development, thus it is impossible if using the waterfall model to move on to the next phase.David Parnas, in A Rational Design Process: How and Why to Fake It, writes:[5]“Many of the [system's] details only become known to us as we progress in the [system's] implementation. Some of the things that we learn invalidate our design and we must backtrack.”The idea behind the waterfall model may be "measure twice; cut once," and those opposed to the waterfall model argue that this idea tends to fall apart when the problem constantly changes due to requirement modifications and new realizations about the problem itself. A potential solution is for an experienced developer to spend time up front on refactoring to consolidate the software, and to prepare it for a possible update, no matter if such is planned already. Another approach is to use a design targeting modularity with interfaces, to increase the flexibility of the software with respect to the design.[edit] Modified modelsIn response to the perceived problems with the pure waterfall model, many modified waterfall models have been introduced. These models may address some or all of the criticisms of the pure waterfall model.[citation needed] Many different models are covered by Steve McConnell in the "lifecycle planning" chapter of his book Rapid Development: Taming Wild Software Schedules.
- Discipline: rhythm, daily scrum, work agreements, consistentAgile approach is Great Risk Management:Risk of not pleasing the customerRisk of poor estimation and planningRisk of festering issues and delaysRisk of over-commitmentRisk of not being able to ship
- Recognition of real need for the professionWill bestow PMI credibility and supportAgile is best learned by practicing. I'm not too particular on how one learns, but putting the learning into practice in a team environment with frequent and effective retrospectives to adjust your process is key to internalizing agile. Hopefully the experience qualification ensures real agile project experience, not just observing agile teams. Experience requirement: working on Agile project teams, may be other role than Project Manager.
- Plan-driven software methodologies use a command-and-control approach to projectmanagement. A project plan is created that lists all known tasks. The project manager’sjob then becomes one of enforcing the plan. Changes to the plan are typically handledthrough “change control boards” that either reject most changes or they institute enoughbureaucracy that the rate of change is slowed to the speed that the plan-drivenmethodology can accommodate. There can be no servant-leadership in this model.Project managers manage: they direct, administer and supervise.Agile project management, on the other hand, is much more about leadership than aboutmanagement. Rather than creating a highly detailed plan showing the sequence of allactivities the agile project manager works with the customer to layout a common set ofunderstandings from which emergence, adaptation and collaboration can occur. The agileproject manager lays out a vision and then nurtures the project team to do the bestpossible to achieve the plan. Inasmuch as the manager represents the project to thoseoutside the project he or she is the project leader. However, the project manager serves anequally important role within the project while acting as a servant to the team, removingtheir impediments, reinforcing the project vision through words and actions, battlingorganizational dysfunctionality, and doing everything possible to ensure the success ofthe team. The agile project manager is a true coach and friend to the project teams.
- Old solutions may no longer work for new challenges
- Global bet testing program – Europe, Asia, Americas. It’s closed and invitation based. In Asia we have 4 countries running the program (Japan, Korea, Taiwan, China) and we are eager to add more countriesBenefits – gain unique experiences how SW is developing and testing, direct communication with Skype engineers provided with dedicated access to internal information system incentive program beta testers’ high involvement in developing Skype – Bug fix, Quality testing, Localizations
- Send mail to Beom that you are interested in participating the program and he will give further info.
- 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://academic.research.microsoft.com/Publication/4327025/historical-roots-of-agile-methods-where-did-agile-thinking-come-fromBoehm http://academic.research.microsoft.com/Publication/3167904/guidelines-for-verifying-and-validating-software-requirements-and-design-specifications