PMBOK and Scrum: Best of both worlds

9,574 views

Published on

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
5 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
9,574
On SlideShare
0
From Embeds
0
Number of Embeds
207
Actions
Shares
0
Downloads
542
Comments
0
Likes
5
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;
  • 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
  • PMBOK and Scrum: Best of both worlds

    1. 1. Service<br /> Knowledge<br /> Result<br />PMBOK and Agile: Blending the Best of Both Worlds<br />Silvana Wasitova, PMP, CSM, CSP<br />
    2. 2. About me<br />Waterfall<br />Scrum<br />2<br />
    3. 3. At<br />3<br />
    4. 4. 4<br />© Itecor all rights reserved <br />Titre<br />
    5. 5. History of “Waterfall”<br />Waterfall Model<br />Originated in manufacturing and construction industries<br />Highly structured physical environments => after-the-fact changes are prohibitively costly<br /> 1970: Winston Royce article<br />Showed waterfall as an example of a flawed,non-working model<br />5<br />© Itecor all rights reserved <br />
    6. 6. Winston Royce’s “Grandiose” Model<br />6<br />© Itecor all rights reserved <br />“Single Pass” phased model to cope with US DoDregulatory requirements<br />“I believe in this concept, but the implementation is risky and invites failure.”<br />Winston W. Royce, “Managing the development of large software systems”, Aug 1970<br />
    7. 7. Minimize errors<br />BDUF<br />7<br />© Itecor all rights reserved <br />
    8. 8. Winston Royce’s Recommendation<br />8<br />© Itecor all rights reserved <br />Iterations between phases, hopefully confined to successive steps<br />
    9. 9. Winston Royce’s “Problem” Model<br />9<br />© Itecor all rights reserved <br />Problem:Testing phase, at the end of Development cycle, is the first time the integrated components are “experienced”.<br />Failure may require a major redesign, or modifying the requirements.<br />Can expect up to 100% schedule and/or cost overrun. <br />
    10. 10. History of PMBOK<br />1969: PMI established, foremost advocate for the project management profession<br />1987: First PMBOKEstablished a standard and a lexiconIntroduced formal planning & control<br />10<br />© Itecor all rights reserved <br />
    11. 11. PMBOK Processes<br />11<br />
    12. 12. Scrum Framework: Summary<br />12<br />© Itecor all rights reserved <br />3 Roles<br />(Who)<br />5 Practices<br />(How)<br />4 Artifacts<br />(What)<br />Product Planning<br />Sprint Planning<br />Daily Standup (Scrum)<br />Sprint Review<br />Sprint Retrospective<br />Product Owner<br />Team<br />Scrum Master<br />Product Backlog<br />Sprint Backlog<br />Potentially Shippable Product<br />Burn-down Chart<br />
    13. 13. Times are changing<br />Page #<br />13<br />
    14. 14. xkcd.com<br />Randall Munroe, 2007<br />14<br />© Itecor all rights reserved <br />
    15. 15. The Agile Manifesto - 2001<br />We are uncovering better ways of developing software. <br />Through this work we have come to value:<br />Working software overcomprehensive documentation <br />Individuals and interactions overprocesses and tools <br />Customer collaboration overcontract negotiation<br />Responding to changeoverfollowing a plan<br />That is, while there is value in the items on the right, we value the items on the left more.<br />15<br />© Itecor all rights reserved <br />
    16. 16. Waterfall, Agile and Scrum: Characteristics<br />Waterfall<br />Agile : Iterative Development<br />Emergent Design<br />Upfront, Detailed<br />Specifications<br /><ul><li>Daily “standup” status checks ≤ 15mins
    17. 17. Delivery rhythm in iterations (Sprints)
    18. 18. Demo & Retrospective at end of ea. Sprint  Continuous Improvement</li></ul>Cross-functional & collaborative: Dev & QA<br />Linear hand-offs: Dev then QA<br />XP: eXtreme Programming<br />Teamwork<br />Scrum<br />RUP<br />DSDM<br />Formal process, implemented at end<br />Welcomed, <br />prioritized vs. backlog<br />Change Requests<br /><ul><li> Automated Tests
    19. 19. Pair Programming
    20. 20. Automated / Continuous Builds
    21. 21. TDD: Test-Driven Development
    22. 22. Continuous Deployment</li></ul>At beginning and at delivery<br />Customer / User Involvement<br />Throughout cycle<br />Scrum is the most popular Agile method: 74% of Agile practitioners (2009)<br />16<br />16<br />© Itecor all rights reserved <br />
    23. 23. 3 MONTHS<br />6-10 MONTHS<br />Scrum vs. Waterfall: Time To Market<br /> Faster Time to Market<br /> Higher Quality<br /> Satisfied Customer<br />Scrum<br />Develop & QA<br />Sequential <br />Process-Oriented<br />Collaborative<br />Results-Oriented<br />Spec<br />9 weeks<br />Waterfall<br />3 months<br />Develop & QA<br />Updates<br />Spec<br />12 weeks<br />3-6wks<br />y wks<br />xwks<br />6-10 months<br />© Silvana Wasitova<br />
    24. 24. 18<br />© Itecor all rights reserved <br />64%implemented features are rarely or never used<br />Focusing on customer needs ensures:<br />the right features are built<br />not wasting effort (and resources) on features that are not needed<br />While the figures may vary by company, principle remains:<br />Only build the features that the client/users need<br />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<br />
    25. 25. The biggest danger in Project and Product Management:<br />Building the wrong thing!<br />Page #<br />© Itecor all rights reserved <br />19<br />
    26. 26. Scrum vs. Waterfall<br />Scrum<br />Waterfall<br />Approach<br />Freezes scope, estimates schedule<br />Freezes schedule, estimates scope<br />Client Involvement<br />At beginning and end<br />Frequent collaboration<br />Scope<br />Build “everything in the specs”<br />Build what client really needs, by priority<br />Design<br />Design all features up front<br />Emergent design of few features per iteration<br />Development<br />Linear path across phases<br />Iterative, incorporate learning<br />Delivery<br />“Big Bang” at end<br />Frequent, small increments<br />Continuous functional & unit testing inside iterations<br />Testing<br />Separate phase, after development<br />Cost of Change<br />High<br />Low<br />Requirements<br />Defined up front, rigid<br />Allow changes up to “last responsible moment”<br />Documentation<br />Up front and exhaustive<br />Document only what is built, as needed<br />20<br />© Itecor all rights reserved <br />Team Communication<br />At phase-handoffs<br />Continuous, cross-functional<br />© Itecor all rights reserved <br />20<br />
    27. 27. Project Management: Agile vs. Waterfall approach<br />Agile<br />Waterfall<br />Work Assignment<br />Project Manager<br />Self-organizing team<br />Responsibilities<br />Delineated<br />Shared<br />Task Ownership<br />Separated<br />Shared: all for one, one for all<br />Status reports<br />By Project Manager<br />Transparency, shared knowledge<br />Requirements<br />Defined up-front, signed-of<br />High level, detailed in collaborations<br />Plans<br />Detailed plans upfront<br />Evolutionary planning<br />Changes<br />Not welcome<br />Allow changes up to “last responsible moment”,<br />prioritized<br />© Itecor all rights reserved <br />21<br />
    28. 28. Agile practices are aligned with PMBOK process groups: initiating, planning, executing, monitoring, controlling, closing<br />In each iteration:<br />Planning, executing, monitoring, controlling<br />Manage: Scope, time, cost and quality<br />22<br />© Itecor all rights reserved <br />SURPRISE!<br />
    29. 29. Fundamental Difference<br />Changing requirements <br />≠<br />Scope creep<br />© Itecor all rights reserved <br />23<br />
    30. 30. Cone of Uncertainty<br />PMBoK Estimation variances:<br />Order of magnitude: +75% to -25%<br />Budgetary estimate:+25% to -10%<br />Definitive estimate:<br />+10% to -5% <br />Boehm. 1981<br />© Itecor all rights reserved <br />24<br />
    31. 31. © Itecor all rights reserved <br />25<br />
    32. 32. PMBOK Strengths<br />Process oriented<br />Clearproject kickoff & administrative initiation<br />Enumeration of stakeholders, formalizedcommunication plan<br />More explicitly calls for cost management<br />Outlinesrisk management approach: identification, qualitative and quantitative analysis, response planning<br />26<br />© Itecor all rights reserved <br />
    33. 33. Agile Strengths<br />Empowered, self-organizing team<br />Collaboration, cross-fertilization, shared responsibilities & commitments<br />Allows for adjustments and learnings produce a better results<br />Risk management <br />smaller units of work more accurate<br />Frequent checks  fewer surprises & delays<br />Welcomes voice of the customer<br />© Itecor all rights reserved <br />27<br />
    34. 34. Agile deals with<br />© Itecor all rights reserved <br />28<br />
    35. 35. Agile Solutions to Common Problems<br />© Itecor all rights reserved <br />29<br />
    36. 36. Why Scrum Works<br />Close collaboration with client or proxy<br />better solution<br />better buy-in, increased satisfaction<br />Transparency through daily reviews: <br />early visibility of issues<br />early resolution <br />risk reduction<br />LEAN ‘flow’: frequently delivering business value in small increments<br />Eliminate waste, focus on highest priorities<br />Inspect, adapt, improve: in each iteration<br />© Itecor all rights reserved <br />30<br />
    37. 37. © Itecor all rights reserved <br />Use the right tool for the job<br />31<br />
    38. 38. Decision Criteria: Scrum vs. Waterfall<br />© Itecor all rights reserved <br />32<br />
    39. 39. 33<br />
    40. 40. Collaborate with clients and users<br />Many mistakes are avoidable<br />© Itecor all rights reserved <br />34<br />
    41. 41. Scrum Adoption at <br />Ref: http://agilesoftwaredevelopment.com/blog/artem/lessons-yahoos-scrum-adoption<br />VP of Product Development experimented with scrum in 2004<br />Senior§ Director of Agile Development started in 2005<br />In 2008: <br />3 coaches, each coaching approx. 10 scrum teams/year<br />200 scrum teams world wide, of about 1500+ employees<br />Results in 2008:Average Team Velocity increase estimated at +35% / year,in some cases 300% - 400%<br />Development cost reductionover USD 1 million / year<br />ROI on transition and trainings about 100% in first year<br />Note: 15-20% of people consistently DID NOT like Scrum<br />© Itecor all rights reserved <br />35<br />
    42. 42. General Lessons Learned<br />We get the expected benefits: time, scope, quality<br />Delivering what was promised and expected<br />Right quality, right scope, within agreed time<br />Scope Flexibility: low overhead for change management<br />Working with users allowed to quickly improve the product features<br />QA up-front involvement (and within sprints) results in better product quality & smoother Quality Control<br />Client: higher level of involvement and time commitment, higher satisfaction<br />© Itecor all rights reserved <br />36<br />
    43. 43. PMI Agile Certification<br />Wonderful development, recognition of real need<br />Available May 2011<br />Like PMP, requires experience:<br /><ul><li>1,500 hours working in Agile project teams (any role) or in Agile methodologies in last 2 yrs
    44. 44. 2,000 hours general PM experience in last 5 yrs (or PMP)
    45. 45. 21 hours Training in Agile project management topics </li></ul>More info: http://www.pmi.org/en/Agile/Agile-Certification-Eligibility-Requirements.aspx<br />© Itecor all rights reserved <br />37<br />
    46. 46. The Project Manager’s Role<br />Find the right path<br />© Itecor all rights reserved <br />38<br />
    47. 47. Act at the right time<br />© Itecor all rights reserved <br />39<br />
    48. 48. Stay relevant<br />40<br />
    49. 49. Work as a Team<br />© Itecor all rights reserved <br />41<br />
    50. 50. It does not have to hurt<br />© Itecor all rights reserved <br />42<br />
    51. 51. It’s a brave new world <br />out there<br />© Itecor all rights reserved <br />43<br />
    52. 52. Silvana Wasitova, PMP, CSM, CSP <br />Vevey,Switzerland<br />s.wasitova@itecor.com<br />+41 79 558 05 09<br />slideshare.com/wasitova<br />© Itecor all rights reserved <br />44<br />
    53. 53. 45<br />
    54. 54. References<br /><ul><li>Jeff Sutherland’s blog - http://scrum.jeffsutherland.com/
    55. 55. “The New New Product Development Game” Takeuchi and Nonaka. Harvard Business Review, January 1986
    56. 56. “The PMBOK and Agile: Friends or Foes?”, Mary Gerush and Dave West, Forrester 2009
    57. 57. “Five Myths of Agile Development”, Robert Holler, VersionOne, 2006
    58. 58. Winston W. Royce, “Managing the development of large software systems”, Aug 1970http://www.valucon.de/documents/managing_softwareprojects.pdf
    59. 59. “Diagnosing and Changing Organizational Culture”, Cameron and Quinn, 2006
    60. 60. “Living with Complexity”, Norman, Donald (2011), Cambridge, MA: MIT Press
    61. 61. “Leading Change”, John Kotter
    62. 62. http://www.stickyminds.com/pop_print.asp?ObjectId=10365&ObjectType=COL
    63. 63. “Project Management Body of Knowledge” (PMBOK), 2004
    64. 64. http://agile101.net/2009/08/18/agile-estimation-and-the-cone-of-uncertainty/
    65. 65. http://www.mountaingoatsoftware.com
    66. 66. http://www.agilealliance.org
    67. 67. http://www.c-spin.net/2009/cspin20090204AgileTransformationAtBorland.pdf
    68. 68. Primavera – PMISV presentation by Bob Schatz, Primavera VP of Development, 2005
    69. 69. Why Agile Works http://www.slideshare.net/yourpmpartner/agile-secrets-revealed-whitepaper</li></ul>© Itecor all rights reserved <br />46<br />

    ×