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.

The Agility Continuum

210 views

Published on

A presentation for Agile Arizona 2017. Where is your project on the agility continuum (scale), and what might you tweak to get a little more agility (even in a waterfall culture).

Published in: Technology
  • Be the first to comment

The Agility Continuum

  1. 1. 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
  2. 2. 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
  3. 3. “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.” Who has heard these Sound Bites ?
  4. 4. 4 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. Consider the Agile Founding Fathers No ‘black and white’ agile here! Agilemanifesto.org
  5. 5. 5 The Agility Continuum An approach to increase agility a little bit at a time Waterfall/ Planned Agile/ Flexible
  6. 6. 6 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?
  7. 7. 7 The ‘Simple’ Prototype Waterfall Agile 10DimensionstoAssess
  8. 8. 8 Traditional Strong Controls Sequential Phases Known & Optimized Tasks Low Tolerance for Change Delivery at End The Agility Continuum 1-Dimension A Million Points on the Continuum Where is your team now? Where do you want to be? 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?
  9. 9. 9 Project/Team Dimensions ➢ Governance & Change Management ➢ Scope Management ➢ Schedule Management ➢ Team Management ➢ Cost Management ➢ Quality Management ➢ Communications Management ➢ Risk Management ➢ Vendor Management ➢ Stakeholder Management The Agility Continuum – 2nd Dimension Look familiar to the PMP’s in the room? These are 10 Knowledge Areas in the PMP Process Chart.
  10. 10. 10 • 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. The Agility Continuum - Assessment Scoring
  11. 11. 11
  12. 12. Ready? 12
  13. 13. 13 Project Governance & Change Management The Agility Continuum Characteristics at the endpoints of the spectrum • 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 re- prioritization • 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 re- prioritized every sprint (usually 2 weeks) • Distributed and shared governance – product owner, scrum master, and team W3 W2 W1 0 A1 A2 A3
  14. 14. 14 Scope Management The Agility Continuum Characteristics at the endpoints of the spectrum • 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 possible W3 W2 W1 0 A1 A2 A3
  15. 15. 15 Schedule Management The Agility Continuum Characteristics at the endpoints of the spectrum • 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 W3 W2 W1 0 A1 A2 A3
  16. 16. 16 Team Management The Agility Continuum Characteristics at the endpoints of the spectrum • 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 W3 W2 W1 0 A1 A2 A3
  17. 17. 17 Cost/Budget Management The Agility Continuum Characteristics at the endpoints of the spectrum • 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 W3 W2 W1 0 A1 A2 A3
  18. 18. 18 Quality Management The Agility Continuum Characteristics at the endpoints of the spectrum • 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 re- focus 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 W3 W2 W1 0 A1 A2 A3
  19. 19. 19 Communications Management The Agility Continuum Characteristics at the endpoints of the spectrum • 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 W3 W2 W1 0 A1 A2 A3
  20. 20. 20 Risk Management The Agility Continuum Characteristics at the endpoints of the spectrum • 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 W3 W2 W1 0 A1 A2 A3
  21. 21. 21 Vendor Management The Agility Continuum Characteristics at the endpoints of the spectrum • 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 W3 W2 W1 0 A1 A2 A3
  22. 22. 22 Stakeholder Management The Agility Continuum Characteristics at the endpoints of the spectrum • 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) W3 W2 W1 0 A1 A2 A3
  23. 23. 23 The Agility Continuum How did your project/team score? Can you make any incremental improvements? Which culture/process constraints are holding you back?
  24. 24. 24 Top 10 Agile Accelerators ….. Useful EVEN in a Waterfall World Dimension Agility Accelerator 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
  25. 25. 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? The Agility Continuum
  26. 26. Discussion Time 26

×