John Cutler posted a Hackernoon blog titled "I Hate Kanban ..." with a picture of this board. If you don't want to hate your Kanban, you can optimize it using the strategy below.
Overview
For work that is interrupt driven such as a help desk or call center, a ticketing system is often used. This is essentially a Kanban system where (1) work should be made visible, (2) work in progress should be minimized, and (3) cycle time should be measured.
The problem with Kanban is that it is slow unless certain optimizations are implemented. For most help desks the number of tickets completed per week is measured. This is a velocity measure which is equivalent to average cycle time. How would you do twice as many tickets in half the time? This requires cutting cycle time by 75%.
Context
In 2006, Open View Venture Partners decided to use Scrum as a primary driver of value creation. Scrum was implemented organization-wide in the venture firm (Sutherland and Altman 2009) while simultaneously deploying Scrum in portfolio companies. Four major rounds of funding are in progress supporting over three dozen active portfolio companies at any one time.
The goal is to turn $1B into $10B using Scrum. To do that we needed to Innovate rapidly and then scale the innovation. Scrum is first about innovation (Rigby, Sutherland et al. 2016), then about time to market, then about driving sales that expand market share and increase valuation leading to an IPO or sale of the venture company.
Intronis, a cloud storage and backup portfolio company we sold to Barracuda in 2016 had a problem when we initially invested in the company. They were getting twice as many support calls as they could handle, customers were extremely upset, and revenue was impacted. As Senior Advisor and Agile Coach to Open View, I was asked to go to the company and fix this.
The call center was using a typical ticketing system to handle calls. Using the optimizations described here, cycle time was cut by 75% within six months. The same staff could handle twice as many calls as they were receiving. They had so much spare time they started calling customers proactively to ask how they could help. Here are the critical points of optimization for their Kanban system.
Optimization 1: The Backlog
I met with the Intronis Chief Operating Officer, the Support Manager, and some call center staff and asked if they were handling tickets in right order to maximize revenue for the company. They said they were handling tickets First In First Out and agreed that this was not optimizing the revenue. 20% of customers provide 80% of the revenue and they need a higher level service agreement.
To solve this problem we need a Product Owner for the ticketing system. We quickly agreed that the COO owned this operation and should set priorities.
The second aspect of backlog management that is critical is the Ready state of the backlog. Are backlog items clear, small, and immediately executable? We know a Ready backlog can double production (Jakobsen and Sutherland). At American Healthways when Forbes classified it as one of the fastest growing small companies the CIO asked a Scrum coach to improve the performance of the help desk. The coach looked at the backlog and found the help desk team was wasting a lot of time trying to get information from the end user that was needed to fix the problem. He established a Ready criteria for a backlog item and stopped anyone from working on any item that was not ready. When he started the help desk was doing 1000 tickets a week. Two weeks later they were doing 2000 tickets a week.
A Product Owner for the Kanban is essential for cutting cycle time in half.
Optimization 2: The Team
In order to cut cycle time in half again, the support group needs to work as a team to continuously improve their process. For this, they need a facilitative team leader, a daily meeting, a weekly retrospective, and a commitment from the Product Owner to prioritize 10% of their backlog as process improvement items.
We needed to more than double the process efficiency of the team to take performance to the next level. Process efficiency is the actual work time divided by the calendar time. To calculate the process efficiency, you need to map the value stream of the process. How long does each step take, where are delays occurring, and how much value added work is actually accomplished.
I asked the staff what happened when a customer called. They said most of the time, they needed to get help from the support manager in order to answer customer questions. On the average, it took two hours to get help from the support manager so they could call back and have a second discussion with the customer. So for 10 minutes of real work communicating with the customer, it took two hours and ten minutes of clock time. The process efficiency of this piece of the work was 10/130, less than 10%. I knew it would be even worse when we looked as the rest of the process between the time of first call and completion of the ticket to the customer's satisfaction.
We know that if process efficiency goes over 50% production will double (Jakobsen and Sutherland). I got the Support Manager to be the facilitative team leader with less than a 10 minute response time for questions from his team. We then started digging deeper into the entire value stream for tickets.
Optimization 3: The Company
As we dug further into call center problems I told the CEO that we needed an afternoon session for root cause analysis of bigger problems with call center performance. There were too many bugs generated by developers. And the call center staff didn’t understand the system well enough to resolve customer problems without extensive conversations with multiple experts in both development and support.
The CEO, the COO, the development team, and the call center staff met for an afternoon. We mapped out the entire support process and looked at the root cause of their most difficult problems. We decided that the top priority Kaizen (process improvement) was a weekly meeting between call center and development staff for training and updating the development backlog to reduce defects that were generating the largest number of customer calls.
Within six months the call center achieved a 400% increase in throughput.
Conclusion
Your Kanban will be slow unless you Scrum the Kanban. You need a Product Owner, Product Backlog Refinement, Weekly Planning, a Scrum Master, a Team, a Daily Scrum, a Weekly Retrospective, and companywide commitment to allocated 10% of support time to process improvement. Then you can handle twice the tickets in half the time.
English 
French 
Spanish