Your SlideShare is downloading. ×
PMBOK and Scrum: Best of both worlds
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

Standard text messaging rates apply

PMBOK and Scrum: Best of both worlds

6,972
views

Published on

Comparative study of PMBOK and Scrum, and how they corelate. Presented at the SMP Congress in Lausanne, 27 Apr 2011

Comparative study of PMBOK and Scrum, and how they corelate. Presented at the SMP Congress in Lausanne, 27 Apr 2011

Published in: Business

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

No Downloads
Views
Total Views
6,972
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
405
Comments
0
Likes
4
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
  • 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 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.
  • 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
  • Transcript

    • 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
    • 11. PMBOK Processes
      11
    • 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
    • 16. Waterfall, Agile and Scrum: Characteristics
      Waterfall
      Agile : Iterative Development
      Emergent Design
      Upfront, Detailed
      Specifications
      • Daily “standup” status checks ≤ 15mins
      • 17. Delivery rhythm in iterations (Sprints)
      • 18. Demo & Retrospective at end of ea. Sprint  Continuous Improvement
      Cross-functional & collaborative: Dev & QA
      Linear hand-offs: Dev then QA
      XP: eXtreme Programming
      Teamwork
      Scrum
      RUP
      DSDM
      Formal process, implemented at end
      Welcomed,
      prioritized vs. backlog
      Change Requests
      • Automated Tests
      • 19. Pair Programming
      • 20. Automated / Continuous Builds
      • 21. TDD: Test-Driven Development
      • 22. Continuous Deployment
      At 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
    • 43. PMI Agile Certification
      Wonderful development, recognition of real need
      Available May 2011
      Like PMP, requires experience:
      • 1,500 hours working in Agile project teams (any role) or in Agile methodologies in last 2 yrs
      • 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
    • 54. References
      • Jeff Sutherland’s blog - http://scrum.jeffsutherland.com/
      • 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
      • 57. “Five Myths of Agile Development”, Robert Holler, VersionOne, 2006
      • 58. Winston W. Royce, “Managing the development of large software systems”, Aug 1970http://www.valucon.de/documents/managing_softwareprojects.pdf
      • 59. “Diagnosing and Changing Organizational Culture”, Cameron and Quinn, 2006
      • 60. “Living with Complexity”, Norman, Donald (2011), Cambridge, MA: MIT Press
      • 61. “Leading Change”, John Kotter
      • 62. http://www.stickyminds.com/pop_print.asp?ObjectId=10365&ObjectType=COL
      • 63. “Project Management Body of Knowledge” (PMBOK), 2004
      • 64. http://agile101.net/2009/08/18/agile-estimation-and-the-cone-of-uncertainty/
      • 65. http://www.mountaingoatsoftware.com
      • 66. http://www.agilealliance.org
      • 67. http://www.c-spin.net/2009/cspin20090204AgileTransformationAtBorland.pdf
      • 68. Primavera – PMISV presentation by Bob Schatz, Primavera VP of Development, 2005
      • 69. Why Agile Works http://www.slideshare.net/yourpmpartner/agile-secrets-revealed-whitepaper
      © Itecor all rights reserved
      46