PMBoK and Scrum: can we be friends?


Published on

PMBoK and Scrum: can we be friends? -Scrum Day Asia
Bandung, Indonesia, 24 Nov 2012

Published in: Technology
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • 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;
  • 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 Simo
  • Winston W. Royce,Managing the development of large software systemsProc. IEEE WESCON, Aug 1970Royce’s Son:
  • 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 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 pro­cess 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 pro­cess 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 enter­prise 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.
  • PMBoK and Scrum: can we be friends?

    1. 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. 2. About me Waterfall2 Scrum
    3. 3. 3
    4. 4. A Little bit of history…. 4
    5. 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 & control5
    6. 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 model6
    7. 7. Winston Royce’s “Grandiose” Model “Single Pass” phased model to cope with US DoD regulatory requirements“I believe in this concept, but theimplementation is risky and invites failure.”Winston W. Royce, “Managing the development of largesoftware systems”, Aug 1970 7
    8. 8. Winston Royce’s “Problem” ModelProblem:Testing phase, at the end of Developmentcycle, is the first time the integratedcomponents are “experienced”.Failure may require a major redesign,or modifying the requirements.Can expect up to 100% schedule and/or cost overrun. 8
    9. 9. Winston Royce’s Recommendation Iterations between phases, hopefully confined to successive steps9
    10. 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 Sutherland10
    11. 11. The Agile Manifesto - 2001We 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 planThat is, while there is value in the items on the right, we value the items on the left more.11 11
    12. 12. PMBOK and Scrum: Similarities• Deliver the right thing Scope (on time, on budget) Time Budget 12
    13. 13. The biggest danger inProject and ProductManagement: Building the wrong thing! Page # 13
    14. 14. PMBOK and Scrum: Similarities• Deliver the right thing• Communicate, communicate, communicate 14
    15. 15. From
    16. 16. • Collaborate with clients and users • Many mistakes are avoidable16
    17. 17. PMBOK and Scrum: Similarities• Deliver the right thing• Communicate, communicate, communicate• Progressive elaboration 17
    18. 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. 19. PMBOK and Scrum: Similarities• Deliver the right thing• Communicate, communicate, communicate• Progressive elaboration• Cyclical: Plan, Execute, Monitor & Control 19
    20. 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 quality20
    21. 21. The Scrum Framework21
    22. 22. PMBOK and Scrum: Differences• Agile Focus: Minimize Waste (“Muda” in Lean)• “Heavy” vs. “Light” process, umpteen checklists 22
    23. 23. PMBOK Processes23
    24. 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 Retrospective24
    25. 25. PMBOK and Scrum: Differences• Agile Focus: Minimize Waste (“Muda” in Lean)• “Heavy” vs. “Light” process, umpteen checklists• Maximize “work not done” 25
    26. 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: Sample: government and commercial organizations, no vendors, suppliers or consultants26
    27. 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. 28. Waterfall, Agile and Scrum: Characteristics Waterfall Agile : Iterative Development ScrumSpecifications 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 ImprovementTeamwork Dev then QA collaborative: Dev & QA XP: eXtremeChange Formal process, Welcomed,Requests implemented at end prioritized vs. backlog Programming • Automated Tests • Pair ProgrammingCustomer / User At beginning and • Automated / Continuous Builds • TDD: Test-Driven DevelopmentInvolvement at delivery Throughout cycle • Continuous Deployment Scrum is the most popular Agile method: RUP DSDM 74% of Agile practitioners (2009) 28 28
    29. 29. Scrum vs. Waterfall Waterfall ScrumApproach Freezes scope, estimates schedule Freezes schedule, estimates scopeClient Involvement At beginning and end Frequent collaborationScope Build “everything in the specs” Build what client really needs, by priorityDesign Design all features up front Emergent design of few features per iterationDevelopment Linear path across phases Iterative, incorporate learningDelivery “Big Bang” at end Frequent, small increments Continuous functional & unit testing insideTesting Separate phase, after development iterationsCost of Change High LowRequirements 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 29Team Communication At phase-handoffs Continuous, cross-functional 29
    30. 30. Project Management: Agile vs. Waterfall approach Waterfall AgileWork Assignment Project Manager Self-organizing teamResponsibilities Delineated SharedTask Ownership Separated Shared: all for one, one for allStatus reports By Project Manager Transparency, shared knowledgeRequirements Defined up-front, signed-of High level, detailed in collaborationsPlans Detailed plans upfront Evolutionary planningChanges Not welcome Allow changes up to “last responsible moment”, prioritized 30
    31. 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 Hulet31
    32. 32. Agile Solutions to Common Problems32
    33. 33. Lean, Agile, Scrum: How they relateTwo things in common: Eliminate Waste & Increase Customer ValueWaste: anything which does not advance the process, or add valueValue: 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. 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. 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, etc35 35 25-Nov-12
    36. 36. Fundamental Difference36
    37. 37. PMBOK StrengthsProcess 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 planning37
    38. 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 thing38
    39. 39. Use the right tool for the job 39
    40. 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 Content40
    41. 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. 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: Agile-Certification-Eligibility-Requirements.aspx42
    43. 43. Stay relevant43
    44. 44. 44 It does not have to hurt
    45. 45. It’s a brave new world45 out there
    46. 46. PMBOK and Scrum: Can we live together, happily ever after? Not a marriage, but: Yes - Good, respectful, neighbours46
    47. 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 mapping47
    48. 48. Silvana Wasitova, PMP, CSM, CSP, ACP Lausanne, Switzerland +41 79 558 05 09
    49. 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. 50. Skype Beta Program: RegistrationPre-requisites: • Intermediate level of English (Read & Write) + Native Language • Skype experience at least 1 year • Curiosity for IT technologyContact : Beom Soo Park, Program Manager for APAC
    51. 51. 51
    52. 52. References• Jeff Sutherland’s blog -• “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• “Diagnosing and Changing Organizational Culture”, Cameron and Quinn, 2006• “Living with Complexity”, Norman, Donald (2011), Cambridge, MA: MIT Press• “Leading Change”, John Kotter•• “Project Management Body of Knowledge” (PMBOK), 2004••••• Primavera – PMISV presentation by Bob Schatz, Primavera VP of Development, 2005• Why Agile Works 52
    53. 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. 54. Scrum Adoption at Ref: 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 Scrum54