Downloaded 106 times
Uploaded byJoshua Render
PMI-ACP Domain 1 Agile Principles and Mindset
The document provides an overview of agile principles and methodologies, focusing on frameworks such as Scrum, Kanban, Lean, and Extreme Programming (XP). It outlines key concepts, roles, and practices within these methodologies, highlighting their adaptive nature and the emphasis on collaboration, incremental delivery, and continuous improvement. Additionally, it discusses frameworks like Feature-Driven Development (FDD) and Dynamic Systems Development Methodology (DSDM), emphasizing their unique approaches to managing projects and delivering business value.
More Related Content
Similar to PMI-ACP Domain 1 Agile Principles and Mindset
More from Joshua Render
PMI-ACP Domain 1 Agile Principles and Mindset
- 1. PMI-ACP Domain 1 AgilePrinciples and Mindset
- 2.
- 3. Traditional Scope is fixed Costand schedule are usually variable
- 4. Agile Cost and schedule becomefixed The scope becomes variable
- 5.
- 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.
- 8. Lean Overview Lean is notan 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.
- 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
- 12. Lean Seven CoreConcepts 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
- 13.
- 14. Lean Examples ofWaste 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
- 15.
- 16. Scrum Overview Lightweight Framework fordeveloping and sustaining complex products Lightweight; Simple to understand; difficult to master Three Pillars to Scrum Philosophy Five Values Three roles on the Scrum team
- 17. 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
- 18.
- 19. Scrum: Framework Product Backlog Sprint Sprint Planning Sprint Backlog Daily ScrumSprint Review Sprint Retrospective Increment
- 20.
- 21. 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
- 22. 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.
- 23. 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.
- 24. 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.
- 25. 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.
- 26. 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
- 27. Scrum Events The Sprint 01 Sprint Planning 02 DailyScrum (Daily Standup Meeting) 03 Sprint Review 04 Sprint Retrospective 05
- 28. Scrum: The Sprint • Time-boxedto 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
- 29. Scrum: Sprint Planning • A ceremonyto 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
- 30. Scrum: Daily Scrum • 15minute 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
- 31. Scrum: Sprint Review • This isa 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
- 32. Scrum: Sprint Retrospective • Thisis 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
- 33.
- 34. Kanban Overview • Kanban isa 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
- 35. Queueing Theory andLittle’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.
- 36. Pull System The rateof 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
- 37. Kanban Five Core Practices Define andVisualize the Workflow (Kanban board, CFD) Limit Work-In-Progress (WIP) Measure and Manage Flow Make Process Policies Explicit Use Models to Aid in Improvement
- 38. 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
- 39.
- 40. XP Overview XP focuseson technical best practices Five Core Values Twelve Practices Four Roles
- 41. XP Life Cycle Youcan learn more about XP by reading the Extreme Programming Guide: http://www.extremeprogram ming.org/
- 42.
- 43. XP 12 Practices Pair Programming Planning Game Test Driven Development (TDD) Wholeteam Continuous Integration Refactoring Small Releases Sustainable Pace Collective Code Ownership Coding Standard Simple Design System Metaphor
- 44. 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
- 45. XP 12 Practices: Continuous Process 5. Continuous Integration Codeis checked in and integrated continuously 6. Refactoring Improving the design of the current code 7. Small Releases Frequent and small releases are encouraged
- 46. XP 12 Practices: Programmer Welfare 8. Sustainable Pace Longhours are unsustainable and unproductive over the long term
- 47. XP 12 Practices: Shared Understanding 9. CollectiveCode 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
- 48. 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
- 49. 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
- 50.
- 51. FDD Overview Older Agile Methodology 01 FiveMain 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
- 52. FDD Five Main Steps Developan 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
- 53. FDD Best Practices Visibility of Progressand 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
- 54.
- 55. DSDM Overview A Robust andComprehensive 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
- 56. DSDM Philosophy “best businessvalue emerges when projects are aligned to clear business goals, deliver frequently and involve the collaboration of motivated and empowered people.” – Agile Business Consortium
- 57. DSDM 8 Principles FOCUSON 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
- 58. 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
- 59. DSDM Life Cycle DS 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
- 60. • BUSINESS SPONSOR •BUSINESS VISIONARY • TECHNICAL COORDINATOR • PROJECT MANAGER Roles and Responsibilities – PROJECT LEVEL
- 61. • BUSINESS AMBASSADOR •BUSINESS ANALYST • SOLUTION DEVELOPER • SOLUTION TESTER • TEAM LEADER Roles and Responsibilities – SOLUTION DEVELOPMENT TEAM(SDT)
- 62. • BUSINESS ADVISOR •TECHNICAL ADVISOR • WORKSHOP FACILITATOR • DSDM COACH Roles and Responsibilities – SUPPORTING STAFF
- 63. More Information • AgileBusiness 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
- 64. PMI-ACP Domain 1:Agile Principles and Mindset By Joshua Render https://agile-mercurial.com