Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

PMI-ACP : Lesson 1 : Agile Framework


Published on

This is the first lesson of our 15 lesson series of PMI-ACP Program.

Published in: Technology

PMI-ACP : Lesson 1 : Agile Framework

  1. 1. Agile Framework Saket Bansal PMP, PMI-ACP , CSM , ITIL V3 1
  2. 2.  Essence of Agile Agile Values and Principles Overview of Agile Methods Agile and Traditional Development Methodology APM (Agile Project Management Framework) 2
  3. 3. In the struggle for survival, the fittest win out at the expense of their rivals because they succeed in adapting themselves best to their environment. —Charles Darwin 3
  4. 4.  The United States Department of Defense (DoD) and NASA have used iterative and incremental development (IID) since the 1950s In the 1960s, Evolutionary project management(Evo) was conceptualized by Thomas Gilb. Evo recommends one- to two-week iterations, delivery of product each iteration In 1986, “The New New Product Development Game,” a whitepaper published by Takeuchi and Nonaka Takeuchi and Nonaka discuss the “rugby approach” of dedicated, self-organizing teams 4
  5. 5. “The… ‘relay race’ approach to product development…may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s competitive requirements.” The New New Product Development Game 5
  6. 6. Source: Wikipedia-Photo taken by Maree Reveley (aka Somerslea) 6
  7. 7.  The 1990s saw a flurry of agile approaches Scrum at Easel Corporation Extreme Programming Clear Crystal IBM’s Rational Unified Process Dynamic Systems Development Method (DSDM) 7
  8. 8. Agile software development is a group of softwaredevelopment methods based on iterative and incrementaldevelopment, where requirements and solutions evolvethrough collaboration between self-organizing, cross-functional teams. It promotes adaptive planning, evolutionarydevelopment and delivery, a time-boxed iterative approach,and encourages rapid and flexible response to change. It is aconceptual framework that promotes foreseen interactionsthroughout the development cycle 8
  9. 9. In 2001, a group of 17 “lightweight" methodologists met. The meeting also included the representatives of  eXtreme Programming (XP)  Scrum  DSDM  Adaptive Software DevelopmentPhoto taken by Scott Catron The Salt Lake Valley, The Agile Manifesto was Snowbird, Utah written 9
  10. 10. We are uncovering better ways of developing software by doingit and helping others do it. Through this work we have come tovalue: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a planThat is, while there is value in the items on the right, we value the items on the left more. 10
  11. 11.  Focus on empowered, self-managing teams Autonomous teams do not need the day-to-day intervention of management Management protects team from outside interference Agile teams are amalgamation of varied professional skills Agile team members are able to step in for each other as necessary 11
  12. 12.  Traditionally we measure progress by the percent complete of the functional milestones Agile teams provide actual working product as a status report, “product review” Design changes as the system is built, results in outdated documentation Agile teams prefer face-to-face communication over documentation which is simpler, faster, and more reliable. 12
  13. 13.  Contract negotiation, Identify and define everything and spells out the payment and date specifications Customers become a part of the development process Writing specs down and throwing them over the fence is simply not effective 13
  14. 14.  It’s much easier to respond to change when the organization and the customer share a clear understanding of the project’s status In plan-driven environments, all requirements are specified up front, broken down to the task level and estimated Agile plans follow more of a rolling wave approach using top- down planning 14
  15. 15. The empirical model of process control provides and exercisescontrol through frequent inspection and adaptation forprocesses that are imperfectly defined andgenerate unpredictable and unrepeatable outputs. 15
  16. 16. 16
  17. 17.  Empiricism asserts that knowledge comes from experience and making decisions based on what is known. Three pillars uphold every implementation of empirical process control: • Transparency • Inspection • Adaptation 17
  18. 18. Agile Principles 18
  19. 19.  Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale Business people and developers must work together daily throughout the project. 19
  20. 20.  Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. 20
  21. 21.  Continuous attention to technical excellence and good design enhances agility Simplicity—the art of maximizing the amount of work not done—is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. 21
  22. 22.  We increase return on investment by making continuous flow of value our focus. We deliver reliable results by engaging customers in frequent interactions and shared ownership. We expect uncertainty and manage for it through iterations, anticipation, and adaptation. 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. We boost performance through group accountability for results and shared responsibility for team effectiveness. We improve effectiveness and reliability through situational specific strategies, processes and practices. 22
  23. 23. Agile Methods 23
  24. 24.  Phases Inception, Elaboration, Construction, Transition Disciplines Model, Implementation, Test, Deployment, Configuration Management, Project Management, Environment Philosophies Your staff knows what theyre doing, Simplicity, Agility, Focus on high-value activities, Tool independence, Youll want to tailor the AUP to meet your own needs 24
  25. 25.  Frequent Delivery of Usable Code to Users (required) Reflective Improvement (required) Osmotic Communication Preferably by Being Co-Located (required) Personal Safety Focus Easy Access to Expert Users Automated Tests, Configuration Management, and Frequent Integration 25
  26. 26.  Principles • User involvement is the main key, The project team must be empowered, Frequent delivery of products, Delivering a system that addresses the current business needs, Development is iterative and incremental, Changes are reversible, High level scope and requirements should be base-lined, Testing is carried out throughout the project life-cycle, Communication and cooperation among all project stakeholders Techniques • Timeboxing, MoSCoW, Prototyping, Testing, Workshop, Modelling 26
  27. 27.  Values • Communication, Simplicity, Feedback, Courage, Respect Activities • Coding, Testing, Listening, Designing Practices • Pair programming, Planning Game, Test Driven Development, Whole team, Continuous Integration, Design Improvement, Small Releases, Coding Standards, Collective Code Ownership, Simple Design, System Metaphor, Sustainable Pace 27
  28. 28.  Activities • Develop Overall Model, Build Feature List, Plan By Feature, Design By Feature, Build By Feature, Milestones Best practices • Domain Object Modelling • Developing by Feature • Individual Class (Code) Ownership • Feature Teams • Inspections • Configuration Management • Regular Builds • Visibility of progress and results 28
  29. 29.  Scrum Team Events • Sprints • Sprint Planning Meeting • Sprint Review Meeting • Daily Scrum • Sprint Review Meeting • Sprint Retrospectives Artifacts • Product Backlog • Sprint Backlog 29
  30. 30. Agile Vs. Traditional 30
  31. 31. A project is still a project: • Vision • Life cycle • Requirements • Schedule • Team • Communication mechanisms 31
  32. 32. Waterfall Model Agile Project Life Cycle 32
  33. 33. 33
  34. 34.  Plan all in advance  Plan as you go Work-breakdown  Feature-breakdown structure structure Functional specs  User stories Gantt chart  Release plan Status reports Deliver at the end  Story boards Learn at the end  Deliver as you go Follow the plan  Learn every iteration , Adapt Manage tasks  Manage team Agile : Iterative Traditional 34
  35. 35. Agile Project Management Framework 35
  36. 36. Based On Adaptive Software Development (Highsmith 2000). 36
  37. 37.  Envision: Determine the product vision and project objectives and constraints, the project community, and how the team will work together Speculate: Develop a capability and/or feature-based release plan to deliver on the vision Explore: Plan and deliver running tested stories in a short iteration, constantly seeking to reduce the risk and uncertainty of the project Adapt: Review the delivered results, the current situation, and the team’s performance, and adapt as necessary Close: Conclude the project, pass along key learning, and celebrate. 37
  38. 38.  What is the customer’s product vision? What are the key capabilities required in the product? What are the project’s business objectives? What are the project’s quality objectives? What are the project constraints (scope, schedule, cost)? Who are the right participants to include in the project community? How will the team deliver the product (approach)? 38
  39. 39.  The elevator test statement—an explanation of the project to someone within two minutes—takes the following format: For (target customer) Who (statement of the need or opportunity) The (product name) is a (product category) That (key benefit, compelling reason to buy) Unlike (primary competitive alternative) Our product (statement of primary differentiation) 39
  40. 40.  Clients/customers  Exploration factor Project leader  Delay cost Product manager  Capabilities  Quality Objectives Executive Sponsor  Performance/quality Project Objective Statement attributes Business Objectives  Architectural Guidelines Tradeoff matrix  Issues/risks 40
  41. 41.  Speculating establishes a target and a direction. Speculating isn’t wild risk-taking but “conjecturing something based on incomplete facts or information.” The Speculate phase spotlights product and project. Produce a refined list of scope items Develop a Release Develop detailed Iteration Plans for the next Iteration 41
  42. 42.  Product Backlog • The objective of creating a product backlog is to expand the product vision, through an evolutionary requirements definition process, into a product feature list, or backlog. Release Planning • A release plan presents a roadmap of how the team intends to achieve the product vision within the project objectives and constraints identified in the project data sheet 42
  43. 43.  Iteration 0 helps teams balance anticipation with adaptation. The “0” implies that nothing useful to the customer—stories, in other words—gets delivered in this time period. However, the work is useful to the team. 43
  44. 44. 44
  45. 45.  Iteration Planning and Monitoring Technical Practices Project Community 45
  46. 46.  A traditional project manager focuses on following the plan, whereas an agile leader focuses on adapting successfully to inevitable changes Team has to answer critical questions • Is value, in the form of a releasable product, being delivered? • Is the quality goal of building a reliable, adaptable product being met? • Is the project progressing satisfactorily within acceptable constraints? • Is the team adapting effectively to changes imposed by management, customers, or technology? 46
  47. 47. Conduct the Project Closure , Pass along key learning andcelebrate. 47
  48. 48. Saket BansalSaket.Bansal@iZenBridge.comM: 9910802561Web: www.iZenBridge.comTwitter: Saket_tgLinkedIn: 48