Diese Präsentation wurde erfolgreich gemeldet.
Die SlideShare-Präsentation wird heruntergeladen. ×

Agile Fundamentals

Weitere Verwandte Inhalte

Ähnliche Bücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Ähnliche Hörbücher

Kostenlos mit einer 30-tägigen Testversion von Scribd

Alle anzeigen

Agile Fundamentals

  1. 1. Agile Fundamentals<br />
  2. 2. The Agile EnterpriseStrategically Aligned, Throughput Focused, Human Powered<br />“Dennis Stevens helped us develop a structured approach that connected customer value to execution. He helped us deliver over $200 million in value to our customers.” <br />-- Ric Merrifield, Microsoft Corporation<br /><ul><li>OPM3
  3. 3. PMI Agile LIG
  4. 4. PMI Agile CoP
  5. 5. PMI Agile Certification</li></ul>“Dennis Stevens helped us align business analysis, architecture, development, QA, support and implementation. He was an advocate for the success of our business" <br />-- Rob Andes, CTO, John Deere<br />Connecting the Strategy and ExecutionHBR: The Next Revolution in Productivity<br />Agile in the Enterprise<br />Core Team Member<br />“In a time growth and change, Dennis Stevens helped us identify and develop the capabilities needed to deliver technology that was critical to our success." <br />-- Mike Rouse, COO, Security First Network Bank<br />Exploiting Agile Development<br />Cutter: Rethinking the Agile Enterprise<br />Agile Business Analysis<br />Agile Extension to the BABOK<br />
  6. 6. Agenda<br />Roots of Agile<br />Agile Manifesto<br />Agile Flavors<br />Agile Roles<br />Agile Ceremonies<br />Agile Fundamental Ideas<br />Q&A<br />
  7. 7. Agenda<br />Roots of Agile<br />
  8. 8. What is Agile?<br />Agile:<br />(adj.) Characterized by quickness, lightness, and ease of movement; nimble.<br />(adj.) Mentally quick or alert.<br />(n.) A group of product development methodologies based on iterative and incremental development, where requirements emerge through feedback with the customer and solutions evolvethrough collaboration between members of self-organizing, cross-functional teams.<br />
  9. 9. Predictive Approach<br />The way Traditional, or Predictive Approach, shapes thedefinition of Scope, control of Project Schedule and Cost, and management of the software development process based on roots in scientific management, plan driven management, and manufacturing<br />
  10. 10. Predictive ApproachScientific Management<br />Frederick Taylor - 1880’s and 1890’s <br />Transformation of Craft Production into Mass Production<br />Work Simplification<br />Specialization<br />Resource Optimization through Time in Motion Studies<br />Piece-rate pay<br />
  11. 11. Initial Benefits in Manufacturing<br />Significant reduction in per unit labor costs<br />Transfer of unskilled agrarian workforce into productive manufacturing resources<br />Standards in productivity<br />Result of Scientific Management in Knowledge Work<br />Low intrinsic value for the skilled worker<br />Low job satisfaction for everyone over time<br />Deskilling and dehumanizing work conditions<br />Increase in management to worker ratio<br />Reduction in innovation<br />Predictive ApproachScientific Management<br />
  12. 12. Predictive ApproachPlan Driven Management<br />Henry Gantt in 1918<br />Henry Ford mass production<br />DoD uses PERT in 1957<br />PMBOK 1987<br />Improve predictability and coordination <br />Define all tasks and efforts upfront<br />Provide a governance (coordination and control) mechanism<br />Upfront definition of all tasks and effort estimates<br />
  13. 13. Predictive ApproachPlan Driven Management<br />Initial Benefits in Manufacturing<br />Mass production<br />Huge expansion of manufacturing<br />Transformation of world economy<br />Result of Plan Driven Approach in Knowledge Work<br />Gains are lost and losses accumulate<br />Delays in delivery<br />Lack of flexibility<br />Over production of work<br />Stifling of innovation<br />
  14. 14. Predictive ApproachWaterfall<br />Documented by Winston Royce in 1970<br />Reduce cost of change<br />Only proceed to the next phase when the prior phase is complete<br />Early identification of defects<br />Protect the organization from changes in personnel through detailed documentation<br />Protect downstream capacity from flawed product upstream<br />
  15. 15. Predictive ApproachWaterfall<br /><ul><li>Initial Benefits of Waterfall
  16. 16. Thorough design of the plant saves costs from miscues
  17. 17. Quality control at each step protects downstream capacity
  18. 18. Results of Waterfall in Knowledge Work</li></ul>Implementation details that become known as we progress invalidates earlier design decisions<br />Lack of transparency<br />Poor risk management<br />Residual technical debt<br />“The Blind Men and the Elephant”<br />
  19. 19. Predictive Approach<br />A focus on process and tools<br />Comprehensive documentation <br />Detailed upfront definition and strong change control<br />Rigorous adherence to a detailed plan<br />The more projects struggle to more these items are emphasized<br />
  20. 20. Agenda<br />Roots of Agile<br />Agile Manifesto<br />
  21. 21. 1994Dynamic SystemDevelopment MethodFormalization of RAD<br />Some had been having better success<br />Timeline<br />2001 Agile Manifesto<br />1960<br />1970<br />1980<br />1990<br />2000<br />1990 - Sutherland & SchwaberScrum PM FrameworkTime-boxed iterations (30 days)Small and co-located, Inspect & adapt<br />Project MercuryNASA<br />1985BarryBoehmSpiral ModelTeam priorizationbased on risk<br />1976Tom GilbEVO EvolutionaryProject Manag.- Adaptive iterations- Fast time to value<br />1995 – Booch,Rumbaugh & JacobsonRational Unified ProcessArchitecture Focus<br />1996 - Beck,Cunningham & JeffriesExtreme ProgrammingEngineering Practices<br />1980GeraldWeinbergAdaptiveProgramming:The New ReligionSmall increments,Customer-drivenfeedback<br />Gerald WeinbergIncremental andIterative Development<br />Half-day iterations<br />Test driven development<br />IBM FederalSystems Division:- Incremental & iterative- Feedback-driven requirements- Evolving design & architecture<br />1986Fred Brooks“No Silver Bullet”Agile Developmentover Waterfal<br />1997 - Jeff de LucaFeature Driven DevelopmentDeliver tangible, working softwarerepeatedly in a timely manner<br />1998 - Alistair CockburnCrystal FamilyPeople & Communications, DesignPrinciples, Domains, Bare Sufficiency<br />1985 - Takeuchi & NonakaThe New New ProductDevelopment Game- Cross-functional team- Self-organizing team- Legitimate power- Sense of mission<br />2000 – Robert CharetteLean DevelopmentStrategic Focus, Lean Production,Risk Entrepreneurship,Stretch Goals<br />FIRSTGENERATION<br />SECONDGENERATION<br />With the help of LuizCláudioParzianello.<br />
  22. 22. What did they have in common?<br />17 software development thought leaders<br />XP, Scrum, DSDM, Adaptive Software Development, Crystal, FDD, and Pragmatic Programming<br />
  23. 23. Agile Manifesto<br />We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:<br />Individuals and interactionsover process and tools<br />Working software over comprehensive documentation<br />Customer collaboration over contract negotiation<br />Responding to change over following a plan<br />That is, while there is value in the items on the right, we value the items on the left more. <br />
  24. 24. Declaration of Interdependence<br />In 2005, 15 Software Development Project Managers got together to discuss how to Project Management must focus to help deliver value from agile teams.<br />
  25. 25. Declaration of Interdependence<br />Agile and adaptive approaches for linking people, projects and valueWe are a community of project leaders that are highly successful at delivering results. To achieve these results:<br />We increase return on investment by making continuous flow of value our focus.<br />We deliver reliable results by engaging customers in frequent interactions and shared ownership. <br />We expect uncertainty and manage for it through iterations, anticipation, and adaptation. <br />We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference. <br />We boost performance through group accountability for results and shared responsibility for team effectiveness. <br />We improve effectiveness and reliability through situationally specific strategies, processes and practices.<br />
  26. 26. Agenda<br />Roots of Agile<br />Agile Manifesto<br />Agile Flavors<br />
  27. 27. Agile ApproachesScrum-Roles and Ceremonies<br />Three Roles<br />Product Owner<br />Team (Delivery Team)<br />Scrum Master<br />Artifacts<br />Product Backlog<br />Sprint Backlog<br />Working Tested Deployable Software<br />Ceremonies<br />Sprint Planning<br />Daily Standup<br />Sprint Review<br />Sprint Retrospective<br />
  28. 28. Agile ApproachesXP-Technical Excellence<br />Fine scale feedback<br />Pair programming<br />Planning game<br />Test Driven Development<br />Whole Team (Acceptance Tests)<br />Continuous Process<br />Continuous Integration<br />Refactoring<br />Small Releases<br />Coding Standards<br />Shared Understanding<br />Collective Code Ownership<br />Simple Design<br />System Metaphor<br />Programmer Welfare<br />Sustainable Pace<br />
  29. 29. Agile ApproachesFeature Driven Development<br />Develop an overall model<br />Develop a high-level model of the system and use peer review and discussion to refine<br />Build a feature list<br />Create a list of features (client valued increment of functionality) from the high level model<br />Plan by feature<br />Progressively elaborate features <br />Design by feature<br />Develop specifications for each feature<br />Build by feature<br />Develop, test, and promote the feature<br />
  30. 30. Agile ApproachesKanban-Ongoing Improvement<br />Make Work Visible<br />A more explicit task board than scrum<br />Limit Work in Progress<br />Explicitly limit the number of tasks, stories, features, and epics<br />Help Work to Flow<br />Focus on optimizing for flow – not optimization or number of projects active at a time<br />Make policies explicit<br />Management inclusion<br />Evolutionary change<br />Improve processes using improvement models based on performance data<br />
  31. 31. Agenda<br />Roots of Agile<br />Agile Manifesto<br />Agile Flavors<br />Agile Roles<br />
  32. 32. Delivery Teams<br />Delivery Team<br />A team that has everything they need to deliver a working increment of tested, documented, deployable software at the end of every sprint.<br />
  33. 33. Delivery Teams<br />Delivery Team<br />
  34. 34. Delivery Teams<br />Developers<br />
  35. 35. Delivery Teams<br />Testers<br />Developers<br />
  36. 36. Delivery Teams<br />Analyst<br />Testers<br />Developers<br />
  37. 37. Delivery Teams<br />Analyst<br />Testers<br />Developers<br />Specialists<br />
  38. 38. Delivery Teams<br />Analyst<br />Testers<br />Developers<br />Generalizing Specialists<br />
  39. 39. Delivery Teams<br />Analyst<br />ProcessCoordinator<br />Testers<br />Developers<br />Generalizing Specialists<br />
  40. 40. Delivery Teams<br />Analyst<br />CSM<br />Testers<br />Developers<br />Generalizing Specialists<br />
  41. 41. Delivery Teams<br />Analyst<br />KanbanMaster<br />Testers<br />Developers<br />Generalizing Specialists<br />
  42. 42. Delivery Teams<br />Analyst<br />TeamLead<br />Testers<br />Developers<br />Generalizing Specialists<br />
  43. 43. Delivery Teams<br />Analyst<br />Steward<br />Testers<br />Developers<br />Generalizing Specialists<br />
  44. 44. Delivery Teams<br />Analyst<br />Scrum Master<br />Testers<br />Developers<br />Generalizing Specialists<br />
  45. 45. Scrum Master<br />Ensures the delivery team is functional and productive<br />Facilitates Daily Stand Up<br />Facilitates Sprint Planning<br />Facilitates Sprint Review<br />Facilitates Retrospective<br />Participates in Release Planning Meeting<br />Removes Impediments<br />Facilitates Improvements<br />
  46. 46. Product Owner<br />Product Owner<br />Analyst<br />Steward<br />Testers<br />Developers<br />Generalizing Specialists<br />
  47. 47. Product Owner<br />Responsible for the business value of the project<br />Ensures the product owner team is functional and productive<br />PO Steward/ rep(s) optionally participate in Daily Stand Up<br />PO Steward and rep(s) prepare for and participate in Sprint Planning<br />PO Steward and rep(s) participate in Sprint Review<br />PO Steward/ rep(s) optionally participate in Retrospective<br />Prepares for and Facilitates Release Planning Meeting<br />Facilitates Product Owner Improvements<br />
  48. 48. Product Owner Team<br />Product Owner<br />
  49. 49. Product Owner Team<br />Product Owner Team<br />A team that has everything they need to:<br /><ul><li>identify and prioritize business value increments,
  50. 50. scope the smallest solution that might possibly deliver on the business value increment,
  51. 51. prepare the runway for the delivery teams,
  52. 52. coordinate the implementation of the business value increment when it is delivered.</li></li></ul><li>Product Owner Team<br />Product Owner<br />Team<br />
  53. 53. Product Owner Team<br />Product Manager<br />
  54. 54. Product Owner Team<br />Product Manager<br />Governance<br />
  55. 55. Product Owner Team<br />Product Manager<br />Governance<br />Business Analyst<br />
  56. 56. Product Owner Team<br />Product Manager<br />Governance<br />Business Analyst<br />UAT / IVV<br />
  57. 57. Product Owner Team<br />Product Manager<br />Governance<br />Business Analyst<br />Project Manager<br />UAT / IVV<br />
  58. 58. Product Owner Team<br />Product Manager<br />Governance<br />User Experience<br />Business Analyst<br />Project Manager<br />UAT / IVV<br />
  59. 59. Product Owner Team<br />Product Manager<br />Steward<br />Governance<br />User Experience<br />Business Analyst<br />Project Manager<br />UAT / IVV<br />
  60. 60. Product Owner Team<br />Product Manager<br />Product Owner<br />Governance<br />User Experience<br />Business Analyst<br />Project Manager<br />UAT / IVV<br />
  61. 61. Product Owner Team<br />Product Manager<br />Product Owner<br />Governance<br />User Experience<br />Business Analyst<br />Project Manager<br />Delivery<br />UAT / IVV<br />
  62. 62. Agenda<br />Roots of Agile<br />Agile Manifesto<br />Agile Flavors<br />Agile Roles<br />Agile Ceremonies<br />
  63. 63. Overall Flow<br />
  64. 64. Visioning<br />
  65. 65. Visioning<br />Product owner<br />Prepares product vision, strategy and goals<br />Participants as needed<br />Everyone proposes a set of Product Stories<br />Not by architecture layer – a discrete set of value<br />Customer value and frequency and business priority<br />Define risks associated stories with the product stories<br />Organizational risk: Does the delivery team do it<br />Technical risk: Do we have the technology to do it<br />Business risk: Do we have clear business outcomes<br />Architecture, UX, and Design<br />Define Architecturally significant stories<br />Perform sufficient design to provide roadmap<br />
  66. 66. Release Planning<br />
  67. 67. Release Planning<br />Release Planning Inputs<br />A focused goal for the release<br />A prioritized set of user stories – business value ranking<br />Risks associated with the stories<br />Release Planning Process<br />The delivery team assesses the groomed backlog<br />Split the stories into small enough to plan<br />Order the stories into the current release (the smallest product where the benefits outweigh the cost of releasing), the following release, and future releases<br />Prioritize the stories and risks in the current release<br />Plan to address risks ahead of the related stories<br />
  68. 68. Specification<br />
  69. 69. Specification<br /><ul><li>Groom the Backlog
  70. 70. Product Owner Team works with Delivery Team to prepare Specifications (Acceptance Criteria, Screenshots, Mock-Ups, Use Case Updates, etc.) for Sprint Planning
  71. 71. Stories will have sufficient specification to allow teams to adequately plan and commit to the Sprint
  72. 72. The delivery team will have sufficient insight prior to the Sprint Planning to responsibly participate in Sprint planning</li></li></ul><li>Sprint Cadence<br />Scheduled in Advance<br /><ul><li>Sprint Planning
  73. 73. Daily Standups
  74. 74. Sprint Review
  75. 75. Retrospective</li></ul>No Surprises<br />
  76. 76. Sprint Planning<br />
  77. 77. Sprint Planning<br /><ul><li>Review the highest priority stories in backlog
  78. 78. Make sure stories are “ready” to be delivered – identify sufficient stories to fill the next sprint
  79. 79. The delivery team will decompose the stories into the tasks required to deliver on the sprint
  80. 80. The tasks will be estimated in ideal hours by the delivery team with no task being greater than 6-8 hours
  81. 81. The delivery team will include tasks to address risks associated with the stories committed in the sprint
  82. 82. Stories may be further split for future sprints by explicitly identifying the acceptance criteria for the current sprint (dirt road, gravel road, etc)</li></li></ul><li>Daily Standup<br />
  83. 83. Daily Standup Meeting<br /><ul><li>Daily Stand-ups are where the team self organizes
  84. 84. These follow the same pattern of drive risk down early and deliver value
  85. 85. Everyone commits to attending the daily standup, being “present” during the standup, and engaging to support the team
  86. 86. Tasks are pulled – not assigned – in the daily standup
  87. 87. Problems are not resolved in the daily standup. After meetings are scheduled at the daily standup – these are placed on a meeting roster or as tasks on the board</li></li></ul><li>Sprint Review/ Product Demo<br />
  88. 88. Sprint Review/ Product Demo<br /><ul><li>The delivery team reviews the stories delivered against the agreed upon acceptance criteria with the product owner team
  89. 89. The product owner team provides feedback on the product and the success of the delivery team
  90. 90. Only 100% completed stories (delivered, tested, deployable, and documented) are presented
  91. 91. Demonstrate completed functionality to interested stakeholders and/or customers</li></li></ul><li>Retrospective<br />
  92. 92. Retrospective<br />This is attended by the delivery team<br />Three questions:<br />What is working?<br />What is not working?<br />What changes can help the team?<br />Candidly focus on overall performance and identify strategies to improve its processes<br />Review retrospective parking lot items capturing during the sprint<br />The team lead / team coach can make suggestions to the team about improving performance<br />Agree to take explicit actions to improve performance<br />Update documentation in the team room to reflect changes<br />Hold the team accountable for the updated working agreements<br />
  93. 93. Agenda<br />Roots of Agile<br />Agile Manifesto<br />Agile Flavors<br />Agile Roles<br />Agile Ceremonies<br />Agile Fundamental Concepts<br />
  94. 94. Agile Fundamental Concepts<br />1. Value Driven Delivery<br />Deliver value by understanding and prioritizing what is important to the customer and the business, providing quality results incrementally, and obtaining feedback to improve the result delivered.<br />
  95. 95. Agile Fundamental Concepts<br />2. Stakeholder Engagement<br />Establishing and maintaining mechanisms that ensure that all current and future interested parties are appropriately participating throughout the lifecycle of the project.<br />
  96. 96. Agile Fundamental Concepts<br />3. Boost Team Performance<br />Boost team performance through creating an environment of trust, learning, collaborative decision making, commitment and conflict resolution, thereby enhancing relationships amongst individual team members.<br />
  97. 97. Agile Fundamental Concepts<br />4. Adaptive Planning<br />Work with the team and the stakeholders to produce and maintain an evolving plan from initiation to close based on goals, business values, risks, constraints, and stakeholder feedback.<br />
  98. 98. Agile Fundamental Concepts<br />5. Problem Detection and Resolution<br />Identify problems, impediments, and risks; determine strategies for dealing with them; and execute the strategy.<br />
  99. 99. Agile Fundamental Concepts<br />6. Continuous Improvement<br />Reflect on performance and improve the quality, effectiveness, and flexibility of the product, process and team and influence the organization in order to better deliver value now and in the future.<br />
  100. 100. Agenda<br />Roots of Agile<br />Agile Manifesto<br />Agile Flavors<br />Agile Roles<br />Agile Ceremonies<br />Agile Fundamental Ideas<br />Q&A<br />
  101. 101. PMI Agile LIG<br />To participate in the Atlanta Agile Community<br />PMI Atlanta Chapter Agile LIG http://www.pmiatlanta.org<br />Scrum Meet-up http://www.meetup.com/agile-38/<br />Agile Atlantahttp://www.agileatlanta.org<br />Participate in the Agile PMI Virtual Community http://www.agile.vc.pmi.org<br />Information about certification including reference bookshttp://www.pmi.org/Agile<br />
  102. 102. Q&A<br />What questions do you have about Agile?<br />

Hinweis der Redaktion

  • Observed that lathe workers across organizations had wide differences in productivity – with most shops falling to the productivity of the lowest worker in the shop.Goals: Transformation of Knowledge work into Tools, Processes, and Documentation
  • The WBS is defined up front – with 100% of the project scope and all deliverables defined up frontThe WBS is used to show all work and dependencies for a projectEstimating the WBS provides an accurate schedule for the projectHolding people to these detailed upfront plans ensures projects are delivered on timeCreating detailed deliverables at the front of the project that resulted in rework and confusion
  • Demonstrated common practice that had been adopted from the manufacturing and construction industriesRoyce actually documented it as a flawed model – although it was and still is common in software development
  • We are uncovering better ways of developing software by doing it and helping others do it.Through this work we have come to value:

×