The Agility Continuum Where is your project (or product or team) on - PowerPoint PPT Presentation

The Agility Continuum Where is your project (or product or team) on the agility scale? Thene Sheehy October, 2017 PMP, ACP, CSP, ScrumStudy SMC & Trainer

Who am I? Thene Sheehy Program Manager/Specialist, Center for Enablement PetSmart, since Nov, 2016 15 years in Telecom IT 8 years in Healthcare IT …. And various others Data Analyst/Architect Data Management Director, App Dev & Project Management Project/Program Manager Scrum Master … Lifelong Learner

Who has heard these Sound Bites ? “We might be the Mobile Dev team, and yes… we are delivering new features every two weeks, but we aren’t agile enough .” “My team plans and delivers upgrades to our vendor package software that the store/merchandise planning team uses. Since we don’t do real Dev work, we can’t be agile .” “Our vendor gives us a MS Project plan for upgrades, and we just plan and deploy it. No need for agile on this. We prefer waterfall .” “We use offshore developers, and offshore testers, so we can’t be agile .” “We can’t deliver to production every 2 weeks, so we shouldn’t use agile.”

Consider the Agile Founding Fathers No ‘black and white’ agile here! We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. 4 Agilemanifesto.org

The Agility Continuum An approach to increase agility a little bit at a time Waterfall/ Planned Flexible Agile/ 5

The Agility Continuum A Million Points on the Continuum Where is your team now? Where do you want to be? Given the culture & constraints, can you be a little more agile? 6

The ‘Simple’ Prototype 10 Dimensions to Assess Waterfall Agile 7

The Agility Continuum 1-Dimension A Million Points on the Continuum Where is your team now? Where do you want to be? Traditional Iterative Strong Controls Highly Iterative Lighter Controls Lightest Controls Sequential Phases Iterate Phases* Iterate Constantly Known & Optimized Tasks Some Tolerance for Change Low Tolerance for Change High Tolerance for Change Delivery in Phases Adaptive & Empirical Delivery at End Ongoing Releases If waterfall is your most appropriate style, can you still gain benefits from some agile techniques? 8

The Agility Continuum – 2 nd Dimension Project/Team Dimensions � Governance & Change Management � Scope Management � Schedule Management � Team Management � Cost Management � Quality Management Look familiar to the � Communications Management PMP’s in the room? � Risk Management These are 10 � Vendor Management Knowledge Areas in � Stakeholder Management the PMP Process Chart. 9

The Agility Continuum - Assessment Scoring Consider one of your projects. • As we discuss each facet of the project, score your project as: • Waterfall level 1, 2, 3 (3 is the extreme) • Agile 1, 2, 3 (3 is the extreme) • Add the Waterfall and Agile points at the bottom of each column (W3 and A3 are 3 points) • Highlight the facet(s)/ dimensions where you want the benefit of Agile Thinking and • Agile Methods, but have constraints or culture holding you back. 10

11

Ready? 12

The Agility Continuum Characteristics at the endpoints of the spectrum Project Governance & Change Management W3 W2 W1 0 A1 A2 A3 Centralized command/control structure Product Owner (PO) take lead for prioritization, • • Project Charter, PBC, FBC – require scope • detailed scope, schedule, and cost up PO funnels and channels other stakeholder • front, and little tolerance for change input PLT includes multiple stakeholders who Product Roadmap is defined but flexible • • govern as a committee PO defines the MVP and releasable Versions • ePMO has oversight and monitors ROI of each enhancement is justified • • progress independently and used in ongoing re- CR’s for all Changes prioritization • PLT governs and approves all changes Scrum Master coaches on process, facilitates • • Strong Project Management role team, removes impediments • Cost estimates determined centrally, by PO is actively involved on a daily basis to clarify • • PM questions, check progress, validate results, and answer business questions Backlog can be groomed constantly, and re- • prioritized every sprint (usually 2 weeks) Distributed and shared governance – product • owner, scrum master, and team 13

The Agility Continuum Characteristics at the endpoints of the spectrum Scope Management W3 W2 W1 0 A1 A2 A3 Pure waterfall – requirements Epics & User Stories can be planned up front in • • documented in advance and approved. Product Roadmap, and loosely planned in Release Phases follow in sequence…. Design, Plan (over multiple Iterations/Sprints). • Dev, Testing, Deployment (no iterations) Adaptive planning approach – scope is loose and • Requirements fully documented, in detail, can be adjusted by Product Owner every iteration. • and signed off by PLT team (or proxies) Kanban approach has no planning; just pick and • All architecture and design is completed pull, whereas scrum includes sprint planning • up front, before any Dev work begins. No Single Product Backlog ensures prioritization is clear • room for error. Product Owner manages Scope and Prioritization • Product Owner defines User Stories with Acceptance • Criteria Requirements evolve as business needs change • Requirements (in User Stories) are small units of work • that can deliver value quickly Lightweight documentation encourages a focus on • conversation with scrum/project team members (and minimizes overhead time) Tasks to deliver each story are handled within the • work for the User Story so that done is ‘done’ (including testing, as much as is possible) User Story work should include the creation of Test • Cases, Test Data, and Automated Tests, where 14 possible

The Agility Continuum Characteristics at the endpoints of the spectrum Schedule Management W3 W2 W1 0 A1 A2 A3 Project tasks are knowable and Short (bi-weekly) cycles for PDCA (plan, dev, check, adjust), • • estimable but do not dictate production releases Project tasks have known dependencies Ongoing releases (anywhere from daily to monthly) • • Schedule is trustable and fixed Release to production in smallest possible units to get • • Low tolerance for schedule changes due maximum value into the hands of the business • to dependencies Stable teams enable stabilizing velocity, enabling accurate • Project schedule is optimized to be work estimates • repeatable Minimized story dependencies enables independent delivery • Project schedule often includes ‘wait into production and simplified planning • times’ for approvals and resource Schedule/work estimates are completed by • availability issues scrum/project/work team to increase accuracy, and ensure Project delays in the early phases crunch clarity/understanding • remaining work toward the same Product Owner protects the project/scrum team from • immovable end date interruptions and distractions during the sprint cycle to ensure Delivery speed and dates provided by they meet commitments • business owner and PM Scrum Master and Product Owner clear daily impediments to • increase team ‘flow’ and help ensure they meet sprint commitments. Project/Scrum team commitments align to sprint end dates; • precision for mid-sprint deliveries not required to reduce overhead; short time-boxes increase accountability Delivery speed and dates provided by team 15 •

The Agility Continuum Characteristics at the endpoints of the spectrum Team Management W3 W2 W1 0 A1 A2 A3 Team members often on multiple Team members are fully allocated to short ‘burst’ projects • • projects to minimize wait times, increase focus, and reduce PM’s often manage multiple projects ‘context switching’ • Team members report directly to their Consistent teams over time increases accuracy of • • ‘resource’ manager, and dotted line estimates, and enables the team to move into the to the PM; priority conflicts arise often ‘performing’ phase (Tuckman model) Project delays for team members Higher team autonomy and responsibility increase • • working the early phases often engagement and quality – team commits based on their compress time schedules for the understanding of work items and recent velocity team members working the latter Scrum master acts a facilitator, negotiator, servant leader • phases (usually QA and Ops) Project Manager ‘cracks the whip’ to • hold on to scope, schedule, cost, and quality expectations 16