How to Optimize Your Kanban

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.

9 Comments

There is much more to Kanban than your 1), 2), 3) Overview. Further optimizations include pragmatic, actionable, evidence-based guidance for customer focus, service orientation, WIP limits (bounded queues including all “backlogs”), demand balanced to capability, pull systems, decoupled replenishment & delivery cadences, Service Delivery & Operations Reviews, Risk & Strategy Reviews, data-driven improvement using models & the scientific method. All of these work well with Scrum but do not require Scrum. In some contexts, adding Scrum can be artificial, counterproductive and even wasteful. All of the above concepts have been well represented in the Kanban community for years and are well-articulated in the book “Essential Kanban Condensed” by David J. Anderson & Andy Carmichael.

The starting point of the Kanban system you mention does not represent an even close to fully mature state of adoption.

In some contexts you could indeed decorate Kanban with scrum style practices and ceremonies, depending on the nature of the work.

You could also introduce complementary practices and cadences such as upstream Kanban, replenishment and release cadences and work policies, etc etc.

When helping organizations move forward
along the path to better agility it is critical that we avoid one size fits all advice. Saying you are doomed to slowness unless you have a very prescriptive set of scrum roles and practices shows a lack of flexibility that strike ma as the antithesis of agility.

Jeff, this is a really good blog. I’ve used to do/train/coach Scrum and now I’ve been mainly evangelizing Kanban. There’s a lot of good ideas that both communities share and I see that we are progressing together, however, currently I’m asking for more rigor on both communities and I’m afraid your blog is mostly a hasty generalization and association fallacy.

Optimization 1: The problem is FIFO queueing (maybe Don Reinertsen is a better source here?) and clarity of the items. The solution is prioritize and improve upstream, not necessarily Product Owner. You’ve jumped to the conclusions too fast. You need more data.

Optimization 2: I agree, but you’ve basically described some of our teachings on KMP I (Kanban System Design) class program at Lean Kanban University, and ironically, process efficiency is not present in any CSM course program I’ve ever seen. There’re studies much prior to your reference here (Mary and Tom Poppendieck, Don Reinertsen comes to my mind). Scrum and Agile don’t have the monopoly of virtues.

Optimization 3: Where is Scrum on this?

I hope you see this comment not as an attack, not as just a ironic dissent voice. I did this just for the improvement of both communities and the market in general.

Interesting article and case study. I read it though as not about optimizing Kanban, but rather, using Kanban to optimize flow in a specific context, and not a problem about lack of a Product Owner, but problems with sequence and selection (optimization 1), system bottlenecks (optimization 2), and little or no feedback loops (optimizations 2 and 3) to improve the Kanban system and organization capability. Many, if not all, the solutions proposed are a part of the Kanban Method in its practices and guidance.

For optimization 1 there is Make policies explicit (Kanban Method practice 2) and Implement feedback loops (practice 5) for Replenishment. Specifically with polices, explicit pull policies on Ready, which in effect define the Definition of Ready. This helps individuals to make decisions about what to pull next, and enables accountability to those policies at the Replenishment Meeting. Yes, a Product Owner, or Service Request Manager or Lead, can help with this, however the role is not required if the Kanban system is sufficiently mature. Note also that the Kanban community has reframed “Backlog” to “Options Pool” or “Pool of Options” and recommends an upstream flow to develop these options to ready them for commitment.

For optimization 2, there is implementing the Service Delivery Review feedback loop where the focus is on the performance of Kanban system (not the team), asking the question of whether the Kanban system is delivering according to the expectations of the customer, and improving the capability of the system to meet and exceed those expectations.

For optimization 3, there is implementing explicit feedback loops for Operations Review and Risk Review to to help with information flow and improvements across the organization.

The “Essential Kanban Condensed” book (mentioned earlier) is a great reference for all of these, as is the “Enterprise Services Planning: Kanban Cadences and Information Flow” presentation by Janice Linden-Reed on David Anderson’s Slideshare.

There are many good lean ideas that can be applied to interrupt driven work. The point of this blog item is that if you don’t prioritize the backlong, don’t work as a team, don’t continuously improve, and don’t optimize the entire value chain, nothing else matters.

We have been teaching this in all Scrum Inc. training since the founding of the company in 2006. The fact that some others aren’t doing this (whether they are teaching Scrum or Kanban) is one of the reasons why the Standish Group data shows that over 50% of so-called “Agile” teams can’t deliver.

I recently attended Michael Sahota’s Certified Agile Leadership (CAL1) training. Through the teachings in the class, I have come to understand that company culture is the single biggest factor to success. I believe the ‘working as a team’ ethos in Scrum is very much geared around building this unity-in-diversity.

Indeed, in the company I currently work for, we assert that ‘truthfulness is the foundation of improvement, and [that] love is the strongest driver of change’.

While Kanban is not devoid of this; Scrum, in its essence, is about the people and I felt it was worth highlighting that much of the successes drawn from Scrum are grounded in the strong human-interaction aspect of team work.

Hi Jeff,
Thanks for sharing the great article.
This will give us a good starting point to kaizen our support team, we have been doing more than twice the works in half the time since the development team using Scrum in 2014 and continue more than 20% every year. Now this will give us some ideas of how to do the same or better for our Support team.