Swarming: How a new approach to support can save DevOps teams from 3rd-line ticket hell
Download as PPTX, PDF3 likes714,926 views
The document discusses how swarming, a new approach to support, can help DevOps teams avoid being stuck in "third-line ticket hell". It describes how BMC replaced the traditional tiered support structure with swarming, where issues are addressed by a collaborative network of specialists. Key benefits of swarming at BMC included improved resolution times, higher customer satisfaction, and freeing resources for new offerings. The document also notes how swarming aligns well with DevOps approaches and could help service management practices evolve to better support DevOps teams.
Swarming: How a new approach to support can save DevOps teams from 3rd-line ticket hell
- 1. Swarming: How a new approach to support can save DevOps teams from 3rd-line ticket hell Jon Hall Principal Product Manager, BMC @jonhall_ DevOps Summit Amsterdam 2018
- 2. The people that excel and create the most value are the ones that step outside their box Hank Barnes, Gartner: “Playing Outside Your Box” May 2018.
- 3. LEVEL 2 SUPPORT LEVEL 2 SUPPORTLEVEL 2 SUPPORT LEVEL 3 SPECIALISTS LEVEL 3 SPECIALISTS LEVEL 3 SPECIALISTS LEVEL 3 SPECIALISTS LEVEL 1 SUPPORT Classic “Tiered” Support Structure @jonhall_
- 4. Escalation Escalation Deconstructing the “Tiered” Support Structure LEVEL 2 SUPPORT LEVEL 2 SUPPORTLEVEL 2 SUPPORT LEVEL 1 SUPPORT LEVEL 3 SPECIALISTS LEVEL 3 SPECIALISTS LEVEL 3 SPECIALISTS LEVEL 3 SPECIALISTS @jonhall_
- 5. …when the answer is here… …or here. Issues may spend time here LEVEL 2 SUPPORT LEVEL 2 SUPPORTLEVEL 2 SUPPORT LEVEL 1 SUPPORT LEVEL 3 SPECIALISTS LEVEL 3 SPECIALISTS LEVEL 3 SPECIALISTS LEVEL 3 SPECIALISTS @jonhall_
- 6. LEVEL 1 SUPPORT LEVEL 2 SUPPORT LEVEL 3 SPECIALISTS When tickets eventually escalate… …they frequently bounce back for clarification @jonhall_
- 7. LEVEL 1 SUPPORT LEVEL 2 SUPPORT LEVEL 3 SPECIALISTS LEVEL 1 SUPPORT LEVEL 3 SPECIALISTS LEVEL 2 SUPPORT SUBJECT MATTER EXPERT The system encourages “heroes” (not in a good way) @jonhall_
- 8. Removing the tiers of support, and calling on the collective expertise of a “swarm” of analysts. Swarming defined @jonhall_ Swarming Network Collaborative Dynamic, loopy Measured by value creation Tiered support Siloes and hierarchies Directed Linear, rigid Measured on activity
- 9. 24 hours, 365 days. 500 specialists, 3000 years of experience 200,000+ incidents addressed each year 10,000+ customers Remedy, Control-M, TrueSight, etc… Communication skills are a hiring focus BMC Contact Centres Support Centres Support Centres Co-located with R&D Pleasanton/ Sunnyvale Houston Austin McLean/ Herndon Lexington Sao Paulo Buenos Aires Spain Dublin Winnersh Amsterdam Paris Tel Hai Pune Singapore Shanghai Beijing Seoul Dalian Tokyo Melbourne Houston, TX, USA Dublin, Ireland Dalian China BMC Customer Support @jonhall_
- 10. Swarming at BMC Dispatch SwarmSeverity 1 Swarm Backlog Swarm @jonhall_
- 11. Severity 1 Swarm Prioritise Swarming Process at BMC @jonhall_
- 12. • Rapid responders • Three agents, one week rotation • Primary focus: Provide immediate response, resolve ASAP Swarm lead Communications Other members Research, coordinate, test Severity 1 Swarm @jonhall_
- 13. Severity 1 Swarm Local Dispatch Swarm Prioritise 30% solved here Swarming Process at BMC @jonhall_
- 14. • “Cherry pickers” • Meet every 60-90 minutes • Primary focus: Can new tickets be resolved immediately? • Also: Validation of ticket details before assignment to specialists Experienced analyst Less-experienced analyst Dispatch Swarm @jonhall_
- 15. Local Product-Line Support Teams Severity 1 Swarm Local Dispatch Swarm Prioritise Swarming Process at BMC @jonhall_
- 16. Local Product Line Support Teams Severity 1 Swarm Local Dispatch Swarm Prioritise Severity 1 Swarm Local Dispatch Swarm Prioritise Local Product Line Support Teams Swarming Process at BMC @jonhall_
- 17. Local Product Line Support Teams Local Product Line Support Teams Backlog Swarm Backlog Swarm Backlog Swarm Swarming Process at BMC @jonhall_
- 18. • Global fixers of troublesome tickets • Meet regularly (often multiple times daily) • Primary focus: Challenging tickets brought by local support teams • Replaces inter-team and individual reassignments Experienced analysts R&D Engineers Backlog Swarms @jonhall_
- 19. • Guidelines, not rules • Metrics had to change (Swarming breaks traditional ones!) • Supported people who became newly customer facing • Banned ticket tennis and direct escalations to experts • New tooling practices, particularly mobile and chat Making it work at BMC Customer Support @jonhall_
- 20. • 25% median resolution time improvement • Customer satisfaction up 8 points • More issues closed in <2 days • Significant reduction in backlogs • Halved on-boarding time • Freed resources for innovative offerings Results at BMC @jonhall_
- 21. “Swarming works better than conventional processes. I am able to get multiple experiences from swarm attendees of similar cases they have worked, and what they did. If there are no experiences, then it’s perspectives: Decades of experience, providing guidance of how to troubleshoot” - Senior Support Analyst, BMC @jonhall_
- 22. “I have probably doubled my knowledge of the products in a year because of Swarming, and I have been here a long time” - Senior Support Analyst, BMC @jonhall_
- 23. Ford Connected Vehicles Division Challenge: how to scale support from 275,000 cars, to 180+ million new vehicles every year. • “You’ve got to go where people are” – Chad Jolly, Developer • Tiered support would mean 4-5 days to get to the right team • First Responders instigate and coordinate ad-hoc swarms for big issues • Other teams have 1 person on rotation for swarming • Swarm may get bigger over time as necessary and might include engineers from Amazon, Microsoft, etc. @jonhall_
- 24. • Costs may increase even as other metrics improve • Difficult to evaluate individual contribution • Organizing across time zones may be a challenge • A few individuals sometimes dominate • Finding the right people for a swarm is difficult It’s not all positive! Problems reported by some Swarming adopters @jonhall_
- 25. “IT organizations that have tried to custom-adjust current tools to meet DevOps practices have a failure rate of 80%” DevOps and the Cost of Downtime: Fortune 1000 Best Practice Metrics Quantified (IDC, 2014) So… what does this all have to do with DevOps? @jonhall_
- 26. • New services and applications suddenly appear • More home-grown software • Developers work in different tools • New kinds of customer, especially external DevOps challenges ServiceDesk orthodoxies… @jonhall_
- 27. • Provision of support at industrial scale • Adaptation to life "on call” • Multi-cloud; Blend of old and new systems • Customer/business context • What to prioritize? Fix or build? …but enterprise realities challenge DevOps DevOps challenges ServiceDesk orthodoxies… @jonhall_
- 28. “The enterprise space doesn’t move slowly because they’re stupid, or they hate technology. It’s because they have users” —Luke Kanies, Puppet Founder, Configuration Management Camp 2015, Belgium. @jonhall_
- 29. • Work-in-progress queues • Asynchronous communication • Single role teams • Individual over-exposure • Lack of knowledge sharing How to annoy a DevOps practitioner @jonhall_
- 30. LEVEL 2 SUPPORT LEVEL 2 SUPPORTLEVEL 2 SUPPORT LEVEL 3 SPECIALISTS LEVEL 3 SPECIALISTS LEVEL 3 SPECIALISTS LEVEL 3 SPECIALISTS LEVEL 1 SUPPORT Uh oh… @jonhall_
- 31. Swarming aligns really well to DevOps • Autonomy and self-organisation • Knowledge transfer and skills development • ChatOps, not email • Prevention of accumulation of queued work • Protection of individuals from burnout @jonhall_
- 32. • Cynefin (Pronounced “kuh-nev-in”) • Developed by Dave Snowden at IBM in 1999 • Taken independent in 2005 • “Signifies the multiple factors in our environment and our experience that influence us in ways we can never understand” Exploring further: Swarming to deliver Cynefin @jonhall_
- 33. @jonhall_ • Obvious and Complicated domains: • Repeating relationship between cause and effect • With Complicated you need to do analysis to find that relationship • Complex domain: • Understanding the problem requires experimentation and analysis. • May, over time, be able to move to Complicated • Chaotic domain: • Dramatic and unconstrained • Focus on damage limitation, try to move to another domain
- 34. “Obvious” Domain @jonhall_ • “Sense, Categorise, Respond” • Template/knowledge-driven resolution • Self service
- 35. “Complicated” Domain @jonhall_ • “Sense, Analyse, Respond” • Dispatch-type swarm – pair agents with varied experience • Capture detailed knowledge for organizational learning
- 36. “Complex” Domain • “Probe, Sense, Respond” @jonhall_
- 37. “Complex” Domain • “Probe, Sense, Respond” @jonhall_
- 38. “Chaotic” Domain • “Act, Sense, Respond” • Sub-swarms • Deal with the acute situation • Try to discover sufficient information to move to complex @jonhall_
- 39. • Service Management needs to evolve its practices and tooling to better position its value to DevOps teams. We need your help to do this right. • We’d like to listen to how support is affecting your role, as your impact grows in your enterprise. • You are agents of change in enterprises, with a good opportunity to influence thinking. What next? @jonhall_
Editor's Notes
- #28: In a company of 4000 people, things can get out of hand really fast if you don't have customer context” “If you're dropped in the middle of something, how did you get here?”\ “The person who is on call at 4am needs to know who has been doing what”