PMBOK and Scrum: Best of both worlds
•Descargar como PPTX, PDF•
9 recomendaciones•7,714 vistas
Comparative study of PMBOK and Scrum, and how they corelate. Presented at the SMP Congress in Lausanne, 27 Apr 2011
Recomendados
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a PMBOK and Scrum: Best of both worlds
Similar a PMBOK and Scrum: Best of both worlds (20)
Más de Silvana Wasitova, Scrum & Agile Coach
Más de Silvana Wasitova, Scrum & Agile Coach (20)
Último
Último (20)
PMBOK and Scrum: Best of both worlds
- 1. Service Knowledge Result PMBOK and Agile: Blending the Best of Both Worlds Silvana Wasitova, PMP, CSM, CSP
- 2. About me Waterfall Scrum 2
- 3. At 3
- 4. 4 © Itecor all rights reserved Titre
- 5. 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 5 © Itecor all rights reserved
- 6. Winston Royce’s “Grandiose” Model 6 © Itecor all rights reserved “Single Pass” phased model to cope with US DoDregulatory 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. Minimize errors BDUF 7 © Itecor all rights reserved
- 8. Winston Royce’s Recommendation 8 © Itecor all rights reserved Iterations between phases, hopefully confined to successive steps
- 9. Winston Royce’s “Problem” Model 9 © Itecor all rights reserved 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.
- 10. History of PMBOK 1969: PMI established, foremost advocate for the project management profession 1987: First PMBOKEstablished a standard and a lexiconIntroduced formal planning & control 10 © Itecor all rights reserved
- 12. Scrum Framework: Summary 12 © Itecor all rights reserved 3 Roles (Who) 5 Practices (How) 4 Artifacts (What) Product Planning Sprint Planning Daily Standup (Scrum) Sprint Review Sprint Retrospective Product Owner Team Scrum Master Product Backlog Sprint Backlog Potentially Shippable Product Burn-down Chart
- 13. Times are changing Page # 13
- 14. xkcd.com Randall Munroe, 2007 14 © Itecor all rights reserved
- 15. The Agile Manifesto - 2001 We are uncovering better ways of developing software. Through this work we have come to value: Working software overcomprehensive documentation Individuals and interactions overprocesses and tools Customer collaboration overcontract negotiation Responding to changeoverfollowing a plan That is, while there is value in the items on the right, we value the items on the left more. 15 © Itecor all rights reserved
- 17. Delivery rhythm in iterations (Sprints)
- 19. Pair Programming
- 20. Automated / Continuous Builds
- 21. TDD: Test-Driven Development
- 22. Continuous DeploymentAt beginning and at delivery Customer / User Involvement Throughout cycle Scrum is the most popular Agile method: 74% of Agile practitioners (2009) 16 16 © Itecor all rights reserved
- 23. 3 MONTHS 6-10 MONTHS Scrum vs. Waterfall: Time To Market Faster Time to Market Higher Quality Satisfied Customer Scrum Develop & QA Sequential Process-Oriented Collaborative Results-Oriented Spec 9 weeks Waterfall 3 months Develop & QA Updates Spec 12 weeks 3-6wks y wks xwks 6-10 months © Silvana Wasitova
- 24. 18 © Itecor all rights reserved 64%implemented features are rarely or never used Focusing on customer needs ensures: the right features are built not wasting effort (and resources) on features that are not needed While the figures may vary by 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-CHAOSSample: government and commercial organizations, no vendors, suppliers or consultants
- 25. The biggest danger in Project and Product Management: Building the wrong thing! Page # © Itecor all rights reserved 19
- 26. Scrum vs. Waterfall Scrum Waterfall 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 iterations Testing Separate phase, after development 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 20 © Itecor all rights reserved Team Communication At phase-handoffs Continuous, cross-functional © Itecor all rights reserved 20
- 27. Project Management: Agile vs. Waterfall approach Agile Waterfall 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 © Itecor all rights reserved 21
- 28. 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 22 © Itecor all rights reserved SURPRISE!
- 29. Fundamental Difference Changing requirements ≠ Scope creep © Itecor all rights reserved 23
- 30. Cone of Uncertainty PMBoK Estimation variances: Order of magnitude: +75% to -25% Budgetary estimate:+25% to -10% Definitive estimate: +10% to -5% Boehm. 1981 © Itecor all rights reserved 24
- 31. © Itecor all rights reserved 25
- 32. PMBOK Strengths Process oriented Clearproject kickoff & administrative initiation Enumeration of stakeholders, formalizedcommunication plan More explicitly calls for cost management Outlinesrisk management approach: identification, qualitative and quantitative analysis, response planning 26 © Itecor all rights reserved
- 33. Agile Strengths Empowered, self-organizing team Collaboration, cross-fertilization, shared responsibilities & commitments Allows for adjustments and learnings produce a better results Risk management smaller units of work more accurate Frequent checks fewer surprises & delays Welcomes voice of the customer © Itecor all rights reserved 27
- 34. Agile deals with © Itecor all rights reserved 28
- 35. Agile Solutions to Common Problems © Itecor all rights reserved 29
- 36. Why Scrum Works Close collaboration with client or proxy better solution better buy-in, increased satisfaction Transparency through daily reviews: early visibility of issues early resolution risk reduction LEAN ‘flow’: frequently delivering business value in small increments Eliminate waste, focus on highest priorities Inspect, adapt, improve: in each iteration © Itecor all rights reserved 30
- 37. © Itecor all rights reserved Use the right tool for the job 31
- 38. Decision Criteria: Scrum vs. Waterfall © Itecor all rights reserved 32
- 39. 33
- 40. Collaborate with clients and users Many mistakes are avoidable © Itecor all rights reserved 34
- 41. 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 reductionover USD 1 million / year ROI on transition and trainings about 100% in first year Note: 15-20% of people consistently DID NOT like Scrum © Itecor all rights reserved 35
- 42. General Lessons Learned We get the expected benefits: time, scope, quality Delivering what was promised and expected Right quality, right scope, within agreed time Scope Flexibility: low overhead for change management Working with users allowed to quickly improve the product features QA up-front involvement (and within sprints) results in better product quality & smoother Quality Control Client: higher level of involvement and time commitment, higher satisfaction © Itecor all rights reserved 36
- 44. 2,000 hours general PM experience in last 5 yrs (or PMP)
- 45. 21 hours Training in Agile project management topics More info: http://www.pmi.org/en/Agile/Agile-Certification-Eligibility-Requirements.aspx © Itecor all rights reserved 37
- 46. The Project Manager’s Role Find the right path © Itecor all rights reserved 38
- 47. Act at the right time © Itecor all rights reserved 39
- 48. Stay relevant 40
- 49. Work as a Team © Itecor all rights reserved 41
- 50. It does not have to hurt © Itecor all rights reserved 42
- 51. It’s a brave new world out there © Itecor all rights reserved 43
- 52. Silvana Wasitova, PMP, CSM, CSP Vevey,Switzerland s.wasitova@itecor.com +41 79 558 05 09 slideshare.com/wasitova © Itecor all rights reserved 44
- 53. 45
- 55. “The New New Product Development Game” Takeuchi and Nonaka. Harvard Business Review, January 1986
- 56. “The PMBOK and Agile: Friends or Foes?”, Mary Gerush and Dave West, Forrester 2009
- 58. “Diagnosing and Changing Organizational Culture”, Cameron and Quinn, 2006
- 59. “Living with Complexity”, Norman, Donald (2011), Cambridge, MA: MIT Press
- 60. “Leading Change”, John Kotter
- 62. “Project Management Body of Knowledge” (PMBOK), 2004
- 67. Primavera – PMISV presentation by Bob Schatz, Primavera VP of Development, 2005
- 68. Why Agile Works http://www.slideshare.net/yourpmpartner/agile-secrets-revealed-whitepaper© Itecor all rights reserved 46
Notas del editor
- 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;
- Context at the time of Royce’s paper in 1970:Programming on punch cards!
- 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
- 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
- Need faster decision making“The world is moving so fast these days that the man who says it can't be done is generally interrupted by someone doing it.” (Elbert Hubbard) “If everything seems under control, you're just not going fast enough.” (Mario Andretti) “If you wish to travel far and fast, travel light. Take off all your envies, jealousies, unforgiveness, selfishness and fears.” (Cesare Pavese) “Moving fast is not the same as going somewhere.” (Dr. Robert Anthony) “Fast is fine, but accuracy is everything.” (Xenophon)Speed of market and technological changeWorld is moving fast(er)!Real-timeNon-linear activities
- Can be on time, on budget, on scope, But still built the wrong product that no one needs.
- 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.
- http://agile101.net/2009/08/18/agile-estimation-and-the-cone-of-uncertainty/Agile Requirements in order of UncertaintyAgile Theme Agile Epic Agile User Story Agile Task In other words estimate SMALL things in hours.Estimating in Fibonacci is the second Agile estimation metric - we call this Story Point Estimation. We use Story Points to estimate larger pieces of work i.e. User Stories and Epics.They work as follows:0,1,2,3,5,8,13,21,34,55,89In other words, a ’5′ is 5x more effort than a ’1′ and an ’8′ is 8x more effort than a ’1′.Story Points can measure things we can’t measure in hours – e.g. complexity – do you include a task for every discussion you don’t yet know you need to have, every time you take 10 minutes out to Google an answer? It is however relatively easy (when you get started) to compare the size of one task/cluster of tasks with another task/cluster of tasks. Estimating in Story Points allows you to take into consideration all sorts of intangible ‘things’ that you sense but can’t quite put your finger on.(See:Software Estimation: The more precise you are, the less accurate you will be)Estimation Using T-Shirt SizesT-shirt Sizing is an Agile Estimation method – it’s used to estimate larger requirements i.e. Epics, but maybe the odd User Story also.In short, you attribute a number of story points to a t-shirt size e.g. an XXL might equal ’55 points’ as shown in the diagram below. T-shirt sizes are great for Product Owners and/or non-technical people as they’re totally abstract and non-threatening (that’s not meant to sound patronising…you know what I mean!). They’re easy to understand.When estimating in T-shirt sizes, it’s still important to set your scale – agree in advance what constitutes a ‘Small’, ‘Large’ and ‘XX Large’.T-shirt sizing will normally take place at the Requirements Workshop – this helps the Product Owner and Product Manager get a sense of scale, which will in turn help with the prioritisation process.As always, the Scrum Team are the people that assign t-shirt sizes to Epics. The Product Owner and/or Product Manager are not allowed to participate in the estimation process – they can offer insight and guidance but the estimations belong to the Scrum Team.Estimation Using Story PointsOnce the Epics have been estimated and prioritised for delivery, they will be broken down into User Stories by the Product Manager and Product Owner.The component User Stories will then be introduced at a subsequent requirements workshop and estimated in Story Points at Poker Planning
- 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
- Ref http://drdobbs.com/tools/229401451?pgno=2 S— Mark Kennaley is president and principal consultant at Fourth Medium Consulting, a Canadian IT management consultancy. His book, SDLC 3.0: Beyond A Tacit Understanding Of Agile, won a Dr. Dobb's 2010 Jolt Productivity Award.the four culture quadrants in the diagram. These include: Clan/Family Culture: Here you have a culture that emphasizes collaboration. Your leaders tend to be facilitators and team builders, who value commitment and communication. They think effectiveness is driven by developing people and spurring participation. Adhocracy Culture: Your company emphasizes creativity and has leaders who are entrepreneurial innovators, who value transformation and agility, and have a high level of risk tolerance. They think that innovation and vision are the best paths to effectiveness. Market Culture: Here the orientation is competition. Your leaders are hard-driving competitors, who emphasize goal achievement, market share, and profitability. Customer focus and aggressive competition lead to effectiveness. Hierarchy/Bureaucracy Culture: Your company tends to focus on control, with leaders who coordinate, monitor, and organize. Efficiency, timeliness, consistency, and risk aversion are the watchwords. Control and efficiency are seen as the best path to effectiveness.
- 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.
- 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
- 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