1. Comparing Agile/Scrum with PMBOK Concepts Elise Hudson, PMP, CSM 2014 PMI Nashville Symposium

2. 2 PMP CSM MPA 20 Years in IT 12 Years in Project Management Cool Jobs

3. Assumptions/Audience Poll Agile/Scrum Refresher PMBOK Concepts (4 th ed.) v. Agile/Scrum Key Questions Resources/Links Questions/Discussion 3

4. Presentation is Based on My Personal Experiences as a PMP Wanted to share some of the information and connections I made, not designed to be comprehensive and cover everything Assuming Pure Agile/Scrum Model Everyone in room has some previous basic understanding of Agile/Scrum Just because I say something happens in Agile doesn’t mean I think it doesn’t already in PMBOK/Waterfall 4

5. How many people have had some Agile/Scrum Training? (CSM, CPO, CSP, CST, ACP) – Anyone with no Agile/Scrum Training? How many people work somewhere with Agile/Scrum projects? – Are they pure or hybrid? How many people struggle with figuring out how to interpret Agile/Scrum and how it works with the PMO in their organizations? – Anyone who has it all figured out? 5

6. Yeah, right. This will never work. This is for people who don’t want process. This introduces more risk than I can express. They Will Get Over It in 6 Months Save me! I quit. Which planet did these people come from? 6

7. Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan See 12 Principles of Agile www.agilemanifesto.org 7

8. Product Focused Iterative Requirements and Solutions – Changeable as Work is In Flight – Super-Responsive to Customer Changes Individually Deliverable Pieces of Work** – Continuous Delivery – Smaller Work Items = Quick Wins Defined Timeboxes for Delivery – Sprints/Releases – Delivery Focused Team-Driven 8

9. Scrum Master – Focuses on Scrum Cadence – Eliminates Impediments – Coaches Team – Is Collaborative Equivalent of Resource Manager Product Owner – Creates/Manages Backlog – Prioritizes User Stories/Backlog Items – Determines Release Schedule (Time or Feature Based) Technical/Development Team Members – Do the Work – Dedicated to the Product/Project (really important) – Ideally Cross-Trained (Developers are Testers, Testers are Developers) – Cross-Functional 9

10. Backlog Grooming Session – Intake for Work/Requirements (typically in user story format) – Prioritization Discussions Sprint Planning – Defining Goals of Sprint – Assignments for Work Sprint – Where the Work Happens – Development and Test Generally Occur in Same Sprint 10

11. Daily Scrum Meetings – What got accomplished yesterday, is planned for today, any impediments Sprint Review – Where the Results of the Sprint are Shown to Customers Sprint Retrospective – Where the Team Evaluates How the Sprint Went 11

12. Non-Traditional Management Structure Utilizes Centers of Excellence That Are Matrixed to Sprint Teams/Processes – Set Standards Across Organization – Like A Steering Committee Financial Reporting Is Completely Product Based – Not Project Based Teams Are Dedicated Work Inputs/Outputs Preferably Determined By Velocity – Velocity = Incoming Backlog Items – Backlog Items Completed in Each Sprint – Do not take on more work than you know you can output Customers Communicate Directly With Product Owners – Directly Involved in Sprint Reviews and Backlog Grooming 12

13. 13

14. Initiating Planning Executing Monitoring/Controlling Closing 14

15. PMBOK Guidelines Reduce Risk – It’s not that we just LOVE process for process’ sake – Process should be designed to reduce risk Project Management Process Evolved from Over 100 Years of Business Research – Empirical Evidence Supports What We Do “A pound of planning is worth a hundred pounds of executing” 15

16. 16

17. PMBOK 17 Agile/Scrum Identify Project Sponsor High Level Scope Assumptions Business Case High Level Budget Identify Ties to Strategic Goals Statement of Work High Level Risks Key Success Measurements Schedule Through Planning Initial WBS Project Approval Processes Conversations between Product Owners and Stakeholders Backlog Item/User Story Gets Created (Maybe) Product Owner responsible for tying back to Strategic Goals

18. PMBOK 18 Agile/Scrum Finalize Scope Requirements Business Functional Technical Design Conversations between Product Owners and Stakeholders Backlog Item/User Story Gets Created (Maybe) Backlog Item/User Story = Requirements AND Design Some Design Can Happen During/With Backlog Grooming

19. PMBOK 19 Agile/Scrum Project Schedule Communications Plan Risk Mitigation Plan Resource Management Plan Project Schedule is Pre-Defined by Backlog and Sprint Schedule Backlogs can be loosely prioritized several sprints ahead Backlog Items/User Stories Scaled to Have No Dependencies Communications Happen Through Product Owner, Backlog Grooming, Sprint Reviews, Status No Real Risk Management Impediments ID’d @ Team Level Resource Management Set with Dedicated Team or handled by Scrum Master for Specialists

20. PMBOK 20 Agile/Scrum Cost Management Plan Quality Management Plan Stakeholder Management Plan Procurement Management Plan Costs are Evenly Spread and Predicted Based on Dedicated Teams and Steady Team Velocity Product Based, not Project Based Quality and Testing Are Addressed in Each Sprint by the Team (They Know the Product Best) Product Owner is Responsible for Stakeholder Management Procurement Management Center of Excellence

21. PMBOK 21 Agile/Scrum Execute Based on Project Plan and Design Mitigate Risks/Issues That Arise Execute Based on Sprint Planning and User Story Definition Product Owner is intimately familiar with Requirements/Backlog Items/User Stories and Is Available in Daily Scrum Meetings to Answer Questions and Provide Clarifications Impediments/Issues/Risks Identified Daily as they arise Scrum Master is Responsible for Facilitating Mitigation (with Team)

22. PMBOK 22 Agile/Scrum Change Requests Scope Schedule Budget Design Risk Management Sprint Planning is the FINAL definition of Scope Once a Sprint Starts, NOTHING about Scope Changes Sprints are Predetermined Time Boundaries Typically 2-4 Weeks Additional Scope Gets Prioritized for Next Sprint RARE to Stop a Sprint No real risk log/Only identification of “impediments” during Daily Scrum Meeting More like issues rather than risks

23. PMBOK 23 Agile/Scrum Status Reports Project Documentation Project Metrics/Analytics Status Happens Fluidly By Scrum Master and Product Owner Being Imbedded with Team (and Daily Scrums) Kanban Board Agile values working software over extensive documentation Some documentation does occur at the User Story/Design level during Sprints as needed Burn-Down/Burn-Up Charts Show if Sprints are on track Velocity Metrics kept by Scrum Master are the primary Metrics Collaborative Accountability

24. PMBOK 24 Agile/Scrum Lessons Learned Project Closeout Documentation Sprint Review Allows Stakeholder Feedback and Communications Sprint Retrospective Provides Team Feedback in Sprint Time Verbal Feedback/Approval from Sprint Review and Retrospective No comprehensive Lessons Learned Typically No Documentation, Any Lessons Learned are Immediately Incorporated into next Sprint’s Activities

25. 25 Majority of Companies do a Hybrid Model where Project Management and the PMO still exist, but product teams practice Agile/Scrum Development Scrum is the most popular form of Agile for Companies Small and Medium Businesses Use Agile More than Large Ones – Median Organization Size for Companies Using Agile is about 100 resources See State of Agile and State of Scrum Reports

26. Smaller, less complex efforts When requirements/scope are unknown or evolving When a dedicated team is present When there are no/few cross-team dependencies When customer/stakeholders are fully engage with Agile/Scrum process When the customer/stakeholders are fully engaged readily available When rapid deployment is needed 26

27. 27 Why do we want to be Agile? How Agile do we want to be? Are we willing to change our organization to be Agile? Will we have dedicated teams for each project? What makes sense in terms of integrating pieces of Agile/Scrum processes for our organization? Do you want to give up Project Based Financials and Schedules in order to be Agile? If a hybrid model, how do we account for the risk of not being pure Agile/Scrum?

28. 28 Agile/Scrum in it’s purest form addresses most concerns and risks that the PMBOK mind may have Most organizations do not utilize a pure Agile/Scrum environment – they use a hybrid, and this leaves many unaddressed risks/concerns (see State of Agile and State of Scrum Reports) Make sure that Project Management is not abandoned before understanding the full transition to Agile/Scrum PMs should have an arsenal of tools for different projects and situations

29. 29 Agile Manifesto – www.agilemanifesto.org The Scrum Guide - https://www.scrum.org/Scrum-Guide Scrum Alliance - http://www.scrumalliance.org/ Scrum Alliance 2013 State of Scrum Report - http://www.scrumalliance.org/scrum/media/ScrumAllianceM edia/Files%20and%20PDFs/State%20of%20Scrum/2013- State-of-Scrum-Report_062713_final.pdf Version One 2013 State of Agile Report - http://stateofagile.versionone.com/ Book on Organizational Changes and Scrum Adoption - The Enterprise and Scrum, Ken Schwaber, Microsoft Press 2007

30. 30 Video - Agile Product Ownership in a Nutshell By Henrick Kniberg - http://www.youtube.com/watch?v=502ILHjX9EE Water-Scrum-Fall is the Reality of Agile for Most Organizations Today by Dave West - http://www.cohaa.org/content/sites/default/files/wate r-scrum-fall_0.pdf Great Agile/Scrum Teacher – Timothy D. Korson at QualSys Solutions – www.qualsys.org

31. 31 Elise Hudson, PMP, CSM elise.hudson@gmail.com (615)787-7049 cell www.linkedin.com/in/elisehudson

32. 32 Questions/Discussion