Customer support messes with our focus
Last-minute chaos seems to be the default unless we diligently apply the discipline to plan. The world of software teams is full of things that can distract us from what we really set out to do. A messy backlog. Too many stakeholders. Recency bias. Cultural issues. Like the sirens in the Odyssey, they tempt us to give up our focus.
Some sirens are well-hidden and take time to uncover. Others stand out instantly whenever I meet a new team. Over the years, I've learned that a clear tell of being unfocused is having multiple Kanban boards per team. Whenever I see that, it guarantees a struggle with focus.
The problem with having multiple Kanban boards is that such a setup serves the planner, not the knowledge worker. A product owner bumps the priority of ticket ABC-123 and can sleep soundly, knowing the devs will pick it up soon. After all, it's now first on the To Do list.
In the meantime, a rival PO will bump a ticket on their board and equally expect the same team to pick it up ASAP. After all, it's first on that To Do list, right?
These kinds of setups where teams need to keep track of multiple Kanban boards are the Agile guru equivalent of a matrix organization where each worker has multiple bosses breathing down their neck.
It offloads the responsibility for planning to the developers under the guise of self-organization. We've set the priorities; now make it work, buddy. It's remarkably common and painfully counterproductive.
It's usually one of the first changes I make in a team. By consolidating the board and having one backlog per team, these conflicts in priorities become visible. It turns into a planning issue for managers rather than passing the buck to the engineers. It's clear to all what is expected of the team, and we can measure focus.
One team, one board has been one of those guiding principles that have worked wonders.
And today, I'm considering breaking that rule.
One of the teams I'm working with has a focus problem. They had Kanban boards for features, infrastructure work, technical debt, and customer support. None of these seemed to get the right amount of attention.
By consolidating the boards, the planning issue becomes clear: customer support and service requests take such a significant toll on the team that getting feature work done is tough. We've set up a single board and applied iterative buffer planning to carve out time for focus.
At the end of each recovery block, the tickets that are left get moved to the next recovery block. We empty the board to make room for focused work.
The problem with customer support, however, is that it often cannot wait until the next recovery block. A user who can't onboard because there’s a typo in their e-mail address needs to be helped. It's not a drop-everything-emergency, but it cannot wait two weeks either.
So, we're experimenting with ways to handle this support load during a focus block. At the end of Mondays and Thursdays, the team will spend one hour collectively handling support tickets to keep up with the flow. These "support swarming sessions" create a context switch, albeit a limited one. By batching this week's support tickets into dedicated timeboxes, we maximize focus while still handling customer support timely.
But that leaves us with an ugly side effect. During focus blocks, there are also support issues on the board. What should be a precise tool for focus is polluted with tickets that we will handle during a timebox later this week. That feels like bad design. There is a clear incentive for the team to handle support at the expense of our focused goal.
So, I'm considering breaking my rule and adding another board just for support items. During those support swarm sessions, the team will look at the support board. For the rest of the focus block, they'll look at the main board.
If this experiment works well, we're one step closer to keeping focus for a team that also has to handle a lot of customer support.