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 Domain 1 Agile Principles and Mindset

Free training for the PMI-ACP Certification exam -

Learn and understand some basic agile concepts.

View training video here: https://agile-mercurial.com/video-library/pmi-acp-domain-1-agile-principles-and-mindset-training-video/

Blog: https://agile-mercurial.com
YouTube: https://www.youtube.com/channel/UCPM82of2YuqIR1SgLGHa1eg
Twitter: https://twitter.com/agile_mercurial
Tumblr: https://agilemercurial.tumblr.com/

PMI-ACP Domain 1 Agile Principles and Mindset

  1. 1. PMI-ACP Domain 1 Agile Principles and Mindset
  2. 2. The Iron Triangle
  3. 3. Traditional Scope is fixed Cost and schedule are usually variable
  4. 4. Agile Cost and schedule become fixed The scope becomes variable
  5. 5. Project Life Cycles
  6. 6. Project Life Cycles • Predictive, Traditional, or Waterfall – work is segmented and sequenced in a predictable flow • Iterative – allows feedback on work that is not completed so that improvements can be made to that work • Incremental – releases of partial work product so that value can be delivered quicker and ongoing work can be used • Adaptive – developed feedback loops, such as iterative, and early value releases, such as incremental, to adapt to changes as the project progresses. Planning is done using progressive elaboration.
  7. 7. Lean
  8. 8. Lean Overview Lean is not an Agile project approach but a set of philosophies that can guide Agile Used heavily in Manufacturing - Lean Manufacturing Consists of Eight Types of Waste Consists of Seven Core Concepts
  9. 9. Lean/Agile Relationship
  10. 10. Lean/Agile Relationship With this model, we can visualize how Agile relates to Lean and what we can learn from Lean to improve Agile
  11. 11. Lean Seven Core Concepts Eliminate Waste •Maximize value by minimizing waste Amplify Learning •Facilitate Communication and elicit feedback Decide Later •Defer Decisions as long as Responsibly Possible Deliver Fast •Maximize Return by gaining value quicker Empower the Team •Give them the knowledge, tools, and environment to do their work Build Integrity In •Test throughout the process See The Whole •Be Aware of the entire system, not just the individual parts
  12. 12. Lean Waste
  13. 13. Lean Examples of Waste Motion – Poor communication within the processes Over processing – Processes that add no value but only add time; bureaucratic processes Over Production – Building features that no one asked for Transportation – Being assigned to different projects, or multitasking Waiting – Waiting for tools, project sign-offs, resources Skills Underutilized – Too many specialists on the team Defects – Bugs in the code Inventory – Creating more documentation than can possible be useful
  14. 14. Scrum
  15. 15. Scrum Overview Lightweight Framework for developing and sustaining complex products Lightweight; Simple to understand; difficult to master Three Pillars to Scrum Philosophy Five Values Three roles on the Scrum team
  16. 16. Scrum: The Three Pillars TRANSPARENCY – Information should be readily available. Information should also not be hidden from stakeholders INSPECTION – The team and other stakeholders should be able to inspect the ‘DONE’ product and make adjustments to the product or process in order to be successful ADAPTATION – The team should be able to adapt to changes or adapt to issues/flaws found during inspection
  17. 17. Scrum: The Five Values Commitment Courage Focus Openness Respect
  18. 18. Scrum: Framework Product Backlog Sprint Sprint Planning Sprint Backlog Daily Scrum Sprint Review Sprint Retrospective Increment
  19. 19. Scrum: Framework
  20. 20. Scrum Team Self Organizing – Team will determine the best way to do the work Cross Functional – Team has all the skills needed to perform the work Deliver Product – Product is delivered in functional pieces iteratively and incrementally
  21. 21. Scrum Role: Product Owner Product Owner – Responsible for maximizing the value of the product and the work of the development team. They are accountable for the Product Backlog and ensuring that the most valuable items are at the top of the list.
  22. 22. Scrum Role: Development Team Development Team – The people who do the actual work of creating and delivering a potentially releasable increment of a DONE product. They have no titles other than “Development Team” and the accountability of creating a DONE increment belongs to the team. There are 3-9 people on a Scrum Development Team.
  23. 23. Scrum Role: Scrum Master Scrum Master – Responsible for ensuring the team understands Scrum. They are servant leader that works to empower the team. They remove blockers or impediments for the development team and facilitate Scrum Events. They support Scrum Adoption and sharing of Scrum Practices throughout the organization.
  24. 24. Scrum Artifacts Product Backlog – An ordered list of what is currently expected to be included in the product. It can change and evolve as new information becomes known. Sprint Backlog – This contains the current product backlog items that are being worked on in the current sprint Increment – The potentially releasable product at the end of a Sprint. It is all of the items in the Sprint Backlog that were brought to a “Done” state.
  25. 25. Definition of DONE (DoD) • This defines when an item from the backlog has been completed • Once it is DONE, it becomes useable • If not defined by the development organization, the Development Team must define it • This should include all things that must go into ensuring that the potentially releasable increment is of high quality and works with all previously released increments, this includes testing
  26. 26. Scrum Events The Sprint 01 Sprint Planning 02 Daily Scrum (Daily Standup Meeting) 03 Sprint Review 04 Sprint Retrospective 05
  27. 27. Scrum: The Sprint • Time-boxed to one month or less • DONE and potentially releasable product increment is created • Sprint lengths should be consistent • New Sprint begins immediately after the previous one ends • Scope may be clarified as more is learned • If a goal becomes obsolete; only the Product Owner may cancel the Sprint
  28. 28. Scrum: Sprint Planning • A ceremony to plan the work to be completed within the Sprint • Time-Boxed to a maximum of 8 hours for a 1 month Sprint, this can be less time for shorter sprints • THE WHAT – What will be worked on? • The Product Owner will discuss what they would like to achieve as the Sprint Goal, but only the Development Team decides on what can be accomplished. • This will form the Sprint Goal • THE HOW – How will this be accomplished? • The team will discuss how they plan to achieve the Sprint Goal
  29. 29. Scrum: Daily Scrum • 15 minute time-boxed ceremony to coordinate and collaborate • Some Agile variants call it the Daily Standup meeting • Three Main Questions • What did I accomplish yesterday? • What am I going to accomplish today? • What are potential impediments or blockers? • Scrum Master ensures the team has the meeting but does not have to attend and does not lead the meeting • It is the Development Teams responsibility to conduct and lead the Daily Scrum • People not on the Development Team are discouraged from attending
  30. 30. Scrum: Sprint Review • This is a 4 hour time-boxed ceremony for one-month Sprints. It can be shorter if the Sprint is shorter. • This provides an opportunity for stakeholders to Inspect the Increment and adapt any changes the product backlog • The Development Team demonstrates what is DONE and receives feedback from the Product Owner, Customers, and other Stakeholders • It occurs near the end of the Sprint
  31. 31. Scrum: Sprint Retrospective • This is a 3 Hour time-boxed ceremony for a month long Sprint. It can be shorter if the Sprint is shorter. • It is held at the end of the Sprint: After the Sprint Review, but before Sprint Planning • The purpose is to Inspect how the Sprint went • Identify what went well and what didn’t go well • Create a plan for improving what didn’t go well and decide on how best to implement the improvement • The team should identify some improvements that can be implemented in the next Sprint
  32. 32. Kanban
  33. 33. Kanban Overview • Kanban is a continuous flow of work with incremental releases • Visualizing the work is very important, and can allow the spotting of bottlenecks between processes • Kanban is a pull system, meaning items must be pulled into the next process • Work in Progress (WIP) limits help maintain a sustainable pace and continuous flow of delivery • Kanban is based off of Just in Time Manufacturing and could be called Just in time delivery • It has Five Core Practices
  34. 34. Queueing Theory and Little’s Law • The validity of Kanban has been shown through the studying of lines • WIP = Throughput * Cycle Time • Named after John Little • It defines the relationship between inventory, the rate of flow, and the time it takes to complete all the processes in the flow.
  35. 35. Pull System The rate of demand from a process controls the flow Items are not pushed forward to the next process if the demand is not present Each process works as an on demand supplier for the process next in line
  36. 36. Kanban Five Core Practices Define and Visualize the Workflow (Kanban board, CFD) Limit Work-In-Progress (WIP) Measure and Manage Flow Make Process Policies Explicit Use Models to Aid in Improvement
  37. 37. Kanban Differences with Typical Agile Continuous Flow – whereas typical Agile uses fixed iterations Key Metric is Cycle Time – whereas many Agile variants use Velocity The Release Methodology – incremental much like other Agile approaches, but it is a continuous incremental flow or at the discretion of the team
  38. 38. Extreme Programming(XP)
  39. 39. XP Overview XP focuses on technical best practices Five Core Values Twelve Practices Four Roles
  40. 40. XP Life Cycle You can learn more about XP by reading the Extreme Programming Guide: http://www.extremeprogram ming.org/
  41. 41. XP Core Values Simplicity Communication Feedback Courage Respect
  42. 42. XP 12 Practices Pair Programming Planning Game Test Driven Development (TDD) Whole team Continuous Integration Refactoring Small Releases Sustainable Pace Collective Code Ownership Coding Standard Simple Design System Metaphor
  43. 43. XP 12 Practices: Fine Scale Feedback 1. Pair Programming Two developers working as a pair; one codes, one reviews 2. Planning Game Release and iterations 3. Test Driven Development (TDD) Write Automated tests first, then code to pass the tests 4. Whole team A team of generalizing specialists sitting together
  44. 44. XP 12 Practices: Continuous Process 5. Continuous Integration Code is checked in and integrated continuously 6. Refactoring Improving the design of the current code 7. Small Releases Frequent and small releases are encouraged
  45. 45. XP 12 Practices: Programmer Welfare 8. Sustainable Pace Long hours are unsustainable and unproductive over the long term
  46. 46. XP 12 Practices: Shared Understanding 9. Collective Code Ownership Team responsibility for code 10. Coding Standard Minimize issues with different approaches 11. Simple Design what Is the simplest thing that could work 12. System Metaphor Tool to create a shared understanding for the team
  47. 47. XP Roles Coach – Mentor and facilitator to the team Customer – Business Representative who determines priorities and requirements for tasks Developers – Develop the software Testers – Test the software
  48. 48. XP Common Practices User Stories – Feature requirements from the perspective of a user Common Format: As a user, I want _____, so that I can ______. Spikes – Reduce risk and uncertainty. Tests or modeling to learn or understand something Architectural Spike – Iteration to prove a technical approach. Helps understand how the product should be built
  49. 49. Feature-Driven Development(FDD)
  50. 50. FDD Overview Older Agile Methodology 01 Five Main Steps, with iterative period being steps 4 and 5 02 Built on a set of best practices aimed at optimizing value 03 Two week implementation period 04
  51. 51. FDD Five Main Steps Develop an Overall Model Output: High Level Object Model and Notes Build a Features List Output: List of Features grouped into sets and subject areas Plan By Feature Output: Development Plan and Feature Set Owners Design By Feature Output: Design Package Build The Feature Output: Programming, Testing, Packaging
  52. 52. FDD Best Practices Visibility of Progress and Results Transparency of the system Regular Build Ensures there is always an up to date build Configuration Management History of changes kept Inspection Code and product should be regularly inspected Feature TeamsFeature Teams Individual Code Ownership Code is assigned to an individual, and that individual is responsible Developing By Feature Developing By Feature Domain Object Modeling Modeling the feature
  53. 53. Dynamic Systems Development Methodology (DSDM)
  54. 54. DSDM Overview A Robust and Comprehensive Approach One of the oldest known forms of Agile, dating back before the Agile Manifesto was created Eight Core Principles Utilizes a MoSCoW approach (Must Have, Should Have, Could Have, Won’t Have) More dedicated roles than other Agile Methodologies, more suitable to larger projects
  55. 55. DSDM Philosophy “best business value emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people.” – Agile Business Consortium
  56. 56. DSDM 8 Principles FOCUS ON THE BUSINESS NEED 1 DELIVER ON TIME 2 COLLABORATE 3 NEVER COMPROMISE QUALITY 4 BUILD INCREMENTALLY FROM FIRM FOUNDATIONS 5 DEVELOP ITERATIVELY 6 COMMUNICATE CONTINUOUSLY AND CLEARLY 7 DEMONSTRATE CONTROL 8
  57. 57. DSDM MoSCoW prioritization Must Have – In order to meet requirements (Customer Demands, Legal Obligations, this is what the release MUST HAVE) Should Have - Extra features it should have but the features are not vital or important Could Have - Wanted or desirable but less impact if not included Won’t Have - Will not be delivered within the timeframe
  58. 58. DSDM Life Cycle D S D M includes phases for pre and post project. The Evolutionary Development phase is where the project work gets conducted. More information on DSDM and the Project Life Cycle can be found at https://www.agilebusiness.org
  59. 59. • BUSINESS SPONSOR • BUSINESS VISIONARY • TECHNICAL COORDINATOR • PROJECT MANAGER Roles and Responsibilities – PROJECT LEVEL
  60. 60. • BUSINESS AMBASSADOR • BUSINESS ANALYST • SOLUTION DEVELOPER • SOLUTION TESTER • TEAM LEADER Roles and Responsibilities – SOLUTION DEVELOPMENT TEAM(SDT)
  61. 61. • BUSINESS ADVISOR • TECHNICAL ADVISOR • WORKSHOP FACILITATOR • DSDM COACH Roles and Responsibilities – SUPPORTING STAFF
  62. 62. More Information • Agile Business Consortium DSDM Handbook: https://www.agilebusiness.org/resources/dsdm- handbooks • Extreme Programming: http://www.extremeprogramming.org/ • The Scrum Guide: https://www.scrumguides.org/ • Comprehensive List of Agile Frameworks: https://agile-mercurial.com/2019/02/06/agile- frameworks-fact-sheet/ • PMI and Agile Alliance (2017) Agile Practice Guide
  63. 63. PMI-ACP Domain 1: Agile Principles and Mindset By Joshua Render https://agile-mercurial.com

    Be the first to comment

    Login to see the comments

  • FaizalSMPMPITILCobit

    Mar. 4, 2019
  • wesamalfaris9

    Mar. 9, 2019
  • ZainTanjim

    Mar. 14, 2019
  • CatanaBrown

    Nov. 3, 2019
  • BharatParekh7

    Jan. 30, 2020

Free training for the PMI-ACP Certification exam - Learn and understand some basic agile concepts. View training video here: https://agile-mercurial.com/video-library/pmi-acp-domain-1-agile-principles-and-mindset-training-video/ Blog: https://agile-mercurial.com YouTube: https://www.youtube.com/channel/UCPM82of2YuqIR1SgLGHa1eg Twitter: https://twitter.com/agile_mercurial Tumblr: https://agilemercurial.tumblr.com/

Views

Total views

1,015

On Slideshare

0

From embeds

0

Number of embeds

498

Actions

Downloads

86

Shares

0

Comments

0

Likes

5

×