The Agility Continuum

Transcription

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

2 Who am I? Thene Sheehy Program Manager/Specialist, Center for Enablement PetSmart, since Nov, 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

3 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.

4 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. Agilemanifesto.org 4

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

6 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

7 The Simple Prototype Waterfall 10 Dimensions to Assess Agile 7

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

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

10 - 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 11

12 Ready? 12

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

14 Characteristics at the endpoints of the spectrum Scope Management W3 W2 W1 0 A1 A2 A3 Pure waterfall requirements documented in advance and approved. Phases follow in sequence. Design, Dev, Testing, Deployment (no iterations) Requirements fully documented, in detail, and signed off by PLT team (or proxies) All architecture and design is completed up front, before any Dev work begins. No room for error. Epics & User Stories can be planned up front in Product Roadmap, and loosely planned in Release Plan (over multiple Iterations/Sprints). Adaptive planning approach scope is loose and can be adjusted by Product Owner every iteration. Kanban approach has no planning; just pick and pull, whereas scrum includes sprint planning Single Product Backlog ensures prioritization is clear 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

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

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

17 Characteristics at the endpoints of the spectrum Cost/Budget Management W3 W2 W1 0 A1 A2 A3 Full scope and schedule defined up front so that cost and ROI can be calculated Changes to cost are avoided and require significant levels of approvals Focus on meeting original cost estimates despite changing business needs during the project Smaller deliverable work units allow for less work to create estimates along with higher accuracy Stable teams enable higher accuracy in cost and schedule estimates Cost estimates are sub-servient to flexible scope to serve changing business needs Work units delivered to production sooner and more frequently increase the overall asset value (because pieces are in production/usage sooner) ROI goes up naturally Cost, value, and ROI are defined per User Story to increase flexibility in delivery schedule Large project estimates are allowed a greater margin of error; re-forecasting is limited to (maybe) quarterly (infrequently, to avoid overhead work Lean Thinking looks for ways to eliminate waste from the project and minimize overhead Total project cost can be estimated based on release plan, list of user stories, story points, and historical team velocity 17

18 Characteristics at the endpoints of the spectrum Quality Management W3 W2 W1 0 A1 A2 A3 Product is tested after fully developed Bugs are found by QA during late-stage testing, long after the developer did the initial work; Developer has to find and refocus attention late in the project Dev team has often moved on to the next round of work when QA team begins and bugs are found Sprint Review/Demo for Product Owner and Stakeholders every 2 weeks holds team accountable for quality delivery throughout Sprint Review/Demo every 2 weeks holds Product Owner accountable to their product; issues are found early when they are less costly to modify (minimize rework) Sprint Review/Demo every 2 weeks keeps PO from business engaged in the project and gets them hooked on seeing the product come to life Integrating testing during development prevents bugs and enables fixing bugs quickly (reducing cost) to increase quality Pair programming shares the testing and quality burden, and increases quality of code, and can increase engagement Sprint Retrospectives every 2 weeks allows the team to reflect and improve process throughout the project lifecycle Including the development of test cases, test data, and automated tests within the sprint helps grow the test bed, and speed testing 18

19 Characteristics at the endpoints of the spectrum Communications Management W3 W2 W1 0 A1 A2 A3 Weekly/Bi-weekly status report is written (spun) by the Project Manager for the management team Communication by the PM with PLT and the project team is less frequent and more formal Use of MS Project often reduces the visibility of status (tough to use tool) Product Owner is actively engaged in the project and needs less formal status reporting Work tools (JIRA/Confluence) make the project information public at all times, and easily shareable Project wiki (confluence space) enable all team members to see and edit project information; tool can present information and capture approvals, when needed JIRA reports can display on project wiki (confluence space) with live up-to-date status information. Scrum Ceremonies keep team members (including Product Owner) engaged and communicating verbally Sprint Planning, Daily Standups, Sprint Review/Demo, Sprint Retrospective Daily Standup helps clear issues quickly and keep the team on track to meet their sprint bi-weekly commitment 19

20 Characteristics at the endpoints of the spectrum Risk Management W3 W2 W1 0 A1 A2 A3 Formal Risk & Issue Logs Formal mitigation planning for risks Risks and Issues often defined by PM and PLT, and less by project team Risks and Issues are often just the major items, and less often include the daily team issues Risk and Issue Logs often reviewed and updated infrequently (along with status) Less formal Risk/Issue logs, if at all Risk Mitigation Tasks in Backlog Risk-adjusted Backlog Daily Impediments may be tracked in JIRA/Confluence, but are often solved without the overhead of tracking Product questions are asked/answered daily by the Product Owner; no time delays 20

21 Characteristics at the endpoints of the spectrum Vendor Management W3 W2 W1 0 A1 A2 A3 Vendor contracts define the full scope of work and expected result (needing more detailed requirements) Vendor contracts often have a high Change Fee with change approval process Vendors often do their work separately from the client with infrequent status reporting and less frequent review/demos Vendor contracts are written to purchase skills and knowledge within a collaborative, iterative approach Changes have no added cost because no detailed scope of work was defined up front Vendor contract defines iterative cycle expectations, and process expectations for bi-weekly re-planning, daily standups, and bi-weekly product reviews; vendor monitoring and accountability is built into the process 21

22 Characteristics at the endpoints of the spectrum Stakeholder Management W3 W2 W1 0 A1 A2 A3 Stakeholders are identified upfront, and PM meets with them to gather their needs, expectations, communication style, risks and issues. Formal stakeholder management is the PM s responsibility PM produces formal status reports for Stakeholders, often different styles for each one Stakeholders often function as a requirements approval committee (and change approval); conflicting priorities often arise Product Owner is chosen to act as front man for stakeholders, and is granted authority to make decisions, prioritize enhancements (user stories), define acceptance criteria, and review/approve work product PO interacts with the Stakeholders, leaving the project/scrum team to focus on developing/delivering the work product Unlike Stakeholders, the PO is intimately involved in the project on a daily basis to clear up questions and impediments immediately Stakeholders and PO have full transparent access to project info whenever they need it, via the work tools (JIRA/Confluence) 22

23 How did your project/team score? Can you make any incremental improvements? Which culture/process constraints are holding you back? 23

24 Top 10 Agile Accelerators.. Useful EVEN in a Waterfall World Governance & Change Management Scope Management Schedule Management Team Management Cost Management Quality Management Communications Management Risk Management Vendor Management Stakeholder Management Fully-involved Product Owner/Manager 3-month Roadmap & 2-week Planning Daily Standups, 2-week Reviews, 3 mo Road-mapping Fully-allocated & Focused Teams Estimates per Item w/frequent Delivery to Production Embedded & Continuous Testing 2-week Reviews & Team Status Wiki (Transparent Information Radiators) Risk-adjusted Backlog & Fully-involved Product Owner/Manager Collaboration without Handoffs Product Owner as Visionary, Prioritizer, Negotiator, Engagement, Newsperson 24

25 Agile is a way of thinking, not a methodology. Even waterfall projects can inject a bit of agile thinking & techniques. Many of the agile techniques are not unique to agile, and useful. All project teams can use agile techniques to improve outcomes. Like yoga, Agile is a Practice which allows for ongoing improvement Agile isn t JUST about the delivery cycle! Where is your team now? How far could you take them? 25

26 Discussion Time 26