Unplanned Work: Options for managing the inevitable
Download as PPTX, PDF0 likes346 views
This document discusses various approaches for managing unplanned work in Agile projects. It begins with the author's experience with unplanned work on past projects. The document then covers sources of unplanned work and associated risks. Several approaches are presented for routing unplanned work through the product owner, using an interrupt buffer in the sprint backlog, dedicating a support team, and leveraging technology and agreements. The document also discusses scaling approaches, using roadmaps for visibility, and leveraging Lean and Scrum practices. Throughout the examples and approaches focus on transparency, inspection, and adaptation to better manage unplanned work.
Unplanned Work: Options for managing the inevitable
- 2. Agile 101: UnplannedWork David Hanson dphanson63@yahoo.com linkedin.com/in/david-hanson/ slideshare.net/DavidHanson5 About the session Unplanned work, whether a traditional project team or an Agile Scrum team, is inevitable. However we have many options for managing that unplanned work beyond reluctant acceptance and working weekends. The session will explore numerous options, from textbook to reality, with a single team or team of teams, leveraging Lean and Agile practices, for all types of unplanned work. About my experience My 1st Agile project (1999-2000) • Worked weekends manually processing what should have been automated • Team members passed pager weekly • Outcome: 100% turnover in 2nd year My 2nd Agile project (2005-2009) First year: • Emergency release every month • Paged almost nightly, including holidays Fourth year: • Follow-the-sun support; paged for escalation at-most quarterly • One issue escalated to resolution board for small error benefiting client 2
- 3. Unplanned Work Any work entering Sprint not identified and pulled during Planning 3
- 5. Unplanned Work Sources: PO changes priority Stakeholders interject Managers interfere UAT defects Production issues IT system priorities Side projects Personal interests Dependent team Discovered work Risks: Sprint goals missed Stakeholders loose confidence Team becomes stressed Lose focus on customer value Context switching reduces velocity Lower value and dark work prevails If unplanned work aligns with sprint goal, then may want to accommodate. 5
- 6. Your approaches to managing unplannedwork? What’s working? Checkmark What’s not? cross mark 6
- 8. Textbook and Reality Route through PO (textbook) Funnel all unplanned work through product owner to review and approve Add to backlog for future sprint, or Negotiate fair trade (add this, drop that) Just Do It (common) If unplanned work is fairly steady, then velocity will find equilibrium If unplanned work comes in spurts, then velocity will be variable To better manage: Log as task to insure visibility Raise in Daily Scrum to acknowledge impact on Sprint Goal Do not point 8 3 pts
- 9. Popular Interrupt Buffer Allocate portion of sprint backlog as buffer for unplanned work Set number of points or fixed capacity If unplanned work is steady, then buffer is predictable If unplanned work is less, then have options when unused buffer If unplanned work is more, then negotiate what drops Set goal to reduce buffer over time 9 Buffer Stories Sprint Backlog
- 10. Scaling Direct unplanned work to dedicated support team Works well when scaling with support aligned to team of teams for common product and clients Escalate to delivery teams as exception Support team follows Kanban Support team pulls less urgent or support-related stories from backlog to smooth flow Consider follow-the-sun model 10 Dedicated SupportTeam
- 11. Technology and Agreements Technology Priorities Default: Scrum master or team educates product owner regarding indirect business value Alternate: Allocate percent of sprint backlog to IT-driven priorities Delegate decision authority to Scrum master or team Useful to accommodate a steady flow of IT priorities If more, then make business case; if less, then address technical debt Working Agreements Incorporate approach into working agreement Consider team member’s, Scrum master’s, and product owner’s role and response to unplanned work Raise awareness with stakeholders, possibly including them in drafting agreement 11
- 12. Roadmaps Make all the work visible, even the unplanned work, and have a conversation. Quarterly Q1 Q2 Q3 Q4 Q5 Strategic Tactical Technology Support Agile Now Next Later Not 12 ongoing level of effort with support-related initiatives defects & enhancements driven by user feedback automation & tech debt initiative upgrade minor minor major minor minor major major minor issue threat opportunity
- 13. MetaScrum Product owner meeting typically weekly or sprintly to manage backlog, dependencies and priorities Ideally new work routed through PO team and Meta Scrum event Should management, support, IT or other stakeholders have a seat at the table? 13
- 14. Lean Practices andAgile Frameworks Lean: make requests visible Lean: address root causes for recurring issues Scrum: Scrum master coaches team, product owner, and organization Scrum: raise as impediment distracting from sprint goal in daily Scrum Scaling: escalate and remove impediments impacting current sprint goal in Scrum of Scrums Scaling: manage or resolve dependencies impacting future sprint goal in Meta Scrum or PI Planning 14
- 16. What’s your path forward? Transparency Inspect and Adapt 16
- 17. Appendix Slack Cross-team Collaboration Other unfinished thoughts on root causes, support, and quality 17
- 18. SlackTime Queueing theory shows that for efficient flow, systems must not be 100% allocated, to allow for the system to absorb perturbations Slack is usually achieved by assuming a lower capacity for individuals 18 Approaches I have used effectively include: • 70% rule: assume 15% time-off and 15% distractions, on-average • 9-day sprints: inserted 1 day between sprints to be used as desired http://brodzinski.com/2015/01/slack-time-value.html
- 19. OurWorking Agreement for Cross-team Collaboration Team Member Request: <1 hour Daily Goal: on target with capacity Decision: yours to do or escalate Else escalate to Scrum Master Scrum Master Request: <1 day SprintGoal: on target with capacity Decision: authorize work and solicit volunteer Else escalate to Product Owner Product Owner Request: aligned with Sprint Goal or urgent & critical Backlog: adjust Sprint Backlog Decision: authorize work and reset expectations Else inform impacted team or stakeholder Backlog: add to Product Backlog Decision: prioritize for future sprint and set expectations 1h 1d ? Drive decision authority as close to work as possible with simple rules as guidelines. 19
- 20. RootCauses Framework as a guide Roles: Lacking true product owner Scrum master not coaching organization Developers shared across teams Artifacts: Unhealthy product backlog Sprint backlog without goal Sprint increments not done Events: Sprints too long Planning without goal or prior refinement Scrum not focused on goal and missing impediments Review without stakeholders and without feedback Retro doesn’t reflect on root causes Framework: Kanban instead of Scrum? 20 Ultimately need to identify and resolve root causes of unplanned work; often root cause points to management.
- 21. Corrective Actions Addressing Issues 1st-time: understand symptoms and document resolution 2nd-time: identify and document root causes 3rd-time: take corrective or preventive action Preventive & Corrective Actions Conduct 5 why’s to get to the root cause Conduct fishbone analysis to identify multiple root causes Leverage Pareto rule An alternate approach: Invest in preventive or corrective action for different levels of root cause 1st why: 20% effort 2nd why: 20% effort … 5th why: 20% effort Approaches that I have used effectively to identify root causes and take preventive or corrective actions. 21 Addressing Defects First create an automated test which will prevent re- introduction of a defect
- 22. The Real Root Cause FiveWhy’s: inevitably identifies management as the root cause Meet with management Impact feedback Training Coaching Consistent and repeated messaging 22
- 23. Support As on-call support, I need… Support is a stakeholder to be invited to sprint reviews Support is a critical user deserving of dedicated stories Support might be covered by an acceptance criteria Working Agreements… Consider support when drafting Definition of Ready Definition of Done WorkingAgreement 23
- 24. We are support New products, small teams; inevitably we will be support Rotating the on-call from sprint to sprint or month to month Builds empathy for those who are on-support as a job Keep this in mind, when asked to sacrifice quality for quantity 24
- 25. Quality Without Quality Without quality, defects increase Resulting in longer schedule and higher costs Scope increases without increasing value Leads to worsening spiral Risk that unplanned work becomes unbearable With Quality With quality, defects decrease Resulting in shorter schedule and lower costs Scope increases with increasing value Leads to continuous improvement Opportunity for unplanned work to be manageable 25
- 26. Failure Failure Sometimes leaders need to allow teams to fail Hero Sometimes heroes need to allow others to learn Sometimes heroes need to allow for failure in order for managers to learn. 26
Editor's Notes
- #3: Action taken on first project: sucked-it-up and soldiered on; given $5K appreciation bonus; exploded under stress Action taken on second project: slowed down, prioritized quality; incremental improvements every month; reorganized around Plan-Build-Operate; productivity increased 4-fold over 4 years
- #4: Purchased image license from 123rf.com
- #6: If unplanned work aligns with sprint goal, then may want to accommodate.
- #8: Swoosh is Nike logo Product owner Just do it Interrupt buffer Dedicated support IT allocation Working agreement Roadmaps Meta Scrum Root cause Not covered: Slack, added to appendix
- #9: Old guide: Team empowered to say no New guide: Team encouraged to say yes, if aligned with sprint goal Addition: graphic displaying steady and variable unplanned work? Swoosh is Nike logo
- #10: Options for unused buffer: retrospective actions, technical debt, continuous learning, next story in product backlog, select a “delighter” or close an “annoyer”.
- #11: Some staff gravitate to support related work. Good option for analysts to develop into PO role. Good option for junior developers to move into development team. Icons licensed from the Noun Project
- #12: http://www.pngall.com/technology-png/download/12848
- #13: Common approaches: quarterly and now-next-later Proportional bandwidth: 40% strategic, 20% tactical, 20% technology, 20% support Tactical: continuous feedback and incremental development needs a feedback loop Technology: makes work visible, opportunity to plan, forces conversation with both IT and business Support: raises visibility and cost; if support transitioned to another team If no support, recommend 4 swim lanes: 50% strategic, 25% feedback, 25% technology Add Q5 or Not to call out what won’t be done; otherwise might be assumed or sneak in as unplanned work Also placeholder to flag risks (threats or opportunities) Make all the work visible, even the unplanned work, and have a conversation.
- #14: Perhaps include SAFe and S@S versions https://miro.medium.com/max/488/1*YlfDzmBfyhg8HVO14av3rw.png
- #15: Lean: focus on flow, not resource, efficiency Lean: build quality in
- #16: Ask participants how these values can help with unplanned work. Openness to acknowledge unplanned work, courage to raise impact on sprint goal, asking to respect the process, to enable our focus, and achieve our commitment to our stakeholders.
- #19: Thanks to Jaysmika Patel for raising this approach. XP 2nd edition formalized this as a planning approach. http://brodzinski.com/2015/01/slack-time-value.html
- #20: Maybe used green check and red mark instead? Drive decision authority as close to work as possible with simple rules as guidelines Possibly rewrite as if then else
- #21: An unfinished slide… Root causes image modified from: https://miro.medium.com/max/2400/1*ZdQ53WPOpjIheXjY2EEewQ.png Fishbone from Wikipedia: By FabianLange at de.wikipedia - Translated from en:File:Ursache_Wirkung_Diagramm_allgemein.svg, GFDL, https://commons.wikimedia.org/w/index.php?curid=6444290
- #22: An unfinished slide… Root causes image modified from: https://miro.medium.com/max/2400/1*ZdQ53WPOpjIheXjY2EEewQ.png Fishbone from Wikipedia: By FabianLange at de.wikipedia - Translated from en:File:Ursache_Wirkung_Diagramm_allgemein.svg, GFDL, https://commons.wikimedia.org/w/index.php?curid=6444290
- #24: Ready: acceptance around logging? Done: updated support or operations wiki? Agreement: transition from Scrum team to support team
- #25: Early manager emphasized: “Think about the person who will be paged at 4 AM when writing and testing your code.”
- #26: https://www.pinterest.com/pin/159807486757869387/
- #27: Sometimes heroes need to allow for failure in order for managers to learn.