Most teams these days are responsible for running their product. Even those who are shielded from the end user through Operators and Support Engineers frequently get called in for second-line support.
As soon as users get involved, there's a never-ending flow of questions, bug reports, and demands. And that messes with our plan.
A while ago, I wrote about an experiment I was running with one of my teams. They applied iterative buffer planning, alternating between focus and recovery blocks. They cleaned up all the old junk from their backlog. And still, they struggled to do what they said they would do.
Every week, without exception, some support tickets would blow up. A user would be on the phone with Customer Success and the team would get asked for a quick, small, urgent intervention. They constantly had to drop everything to help a customer.
These requests are not bug reports. Solving bugs systematically improves the product. And from a planning point of view: most bugs can wait.
No, these customer support requests are the questions or one-off interventions that need our attention without structurally improving the product. They are never really urgent, but they catch fire if we postpone them for too long. Figuring out why that user who can't remember their e-mail address has trouble logging in, isn't a developer's dream job. Not much cerebral enjoyment can be found in handling a GDPR complaint. But these one-off interventions are part of doing business. Customer support is the work we do to keep our users happy. It's incredible how much credit a team can build by being responsive to their customer's needs.
In an attempt to reduce the impact of customer support on day-to-day planning, we introduced Support Swarming Sessions. Two times per week, we get together for an hour to look at the open support tickets and solve them together.
We've been running this experiment for a few months now, and I'd love to discuss the results with you.
Reduced panic
The main benefit of Support Swarming is, without a doubt, increased predictability. When customer requests get handled in a timely fashion, they go away without catching fire. When Customer Success knows the tickets will get picked up every other day, they show more patience. After running this experiment for a while, support is no longer a source of panic. It has become boring, predictable, and under control.
Harmless overflow
Being under control doesn't mean we never had moments of higher demand. Certain sessions ended with a few tickets still on the board. That's fine. By handling the tickets chronologically, whatever gets carried over to the next swarming session is always recent. We never collect old support tickets that way. Instead of waiting two days for the request, the customer now has to wait four days. That is still acceptable. However, this overflow is the exception. Should it become a structural problem, it's a clear sign to extend the session length or plan another session altogether.
Increased knowledge sharing
Since nobody likes support and it doesn't structurally improve the product, we tend to want to get rid of it as soon as possible. The path of least resistance is to ask the engineer who knows the issue best. And that's always the same person. Export users from the old platform? Steve can do this. Reactivate that old user account? Let's ask Steve. Print out a user's billing history? Steeeeheeeeeeve!
By swarming on these support tickets, everyone gets involved. The team members pair on tough problems and certain recurring scenarios get documented or automated. After two months, our Steve is no longer the bottleneck. Support Swarming Sessions have proven to be a great tool for knowledge sharing.
Appreciative Customer Success
One of the most surprising side effects is the improved relationship between first-line and second-line support. When you have an angry customer on the phone, they want to know when their problem is solved. So, traditionally, Customer Success would mark most of their tickets as Urgent in an attempt to appease the customer. When second-line support feels like a black box, ticket priority feels like a lever. Now that they see a bunch of their requests getting answered in bulk every Monday and Thursday, they feel much more confident giving the customer a date. The number of urgent tickets has decreased because they know everything will be solved soon. One of the best benefits is that when they mark something as urgent, it really is, and developers now treat it with the highest priority.
Limited context switch
I was afraid that organizing support swarms during focus blocks would result in two big context switches. Here, the team is in the zone working on that new export functionality when Google Calendar tells them it's time to switch to a potpourri of user complaints. No bueno.
I've learned that scheduling these sessions in the last hour of the day limits the impact of these context shifts. Engineers focus on a single problem the entire day and then spend an hour on support tickets before they go home.
Clean backlog
Finally, separating the support requests from the team backlog has been a great idea. Originally, we polluted the board with all kinds of tickets that have nothing to do with the current focus. During focus blocks, there were also support issues on the board. That gave a clear incentive for the team to handle support at the expense of our focused goal. Splitting the board has been a great design choice. During those Support Swarming Sessions, the team will look at the support board. For the rest of the focus block, they'll look at the main board.
Elegant.
After running this experiment for a few months, the results are stellar. What used to be a source of unpredictability is now under control. I'll be adding Support Swarming Sessions to my regular repertoire.
And so should you.
PS: A number is but a number, but this week, our little niche newsletter has seen its 1000th subscriber. Thank you all for your attention and your feedback.
Here’s to our community bringing reliable long-term planning back to software development! 🍾
Interesting approach. I always thought it is not a good idea to have separate backlogs. And I think in general is not a good idea. But elegantly done like that, with a clear focus, I can see how advantageous it can be. It's like a matter of compartmentalization...