Agile Customer Service: How to Scrum in an Interrupt Environment

Call centers. Service centers. Help desks. They likely define the relationship between you and your customer as anything else you do. When public-facing, their impact on customer satisfaction is second only to the product or service they support. Poor customer support drives business out the door.

When serving internal customers, they can define how well your organization runs. Slow response means slow productivity, lost revenue and opportunities and can be damaging to organizational health and morale.

But service centers are complicated places. Their workflow is inherently unpredictable and contingent on the unexpected.

This is why Scrum, with its focus on both process and product, is perfectly suited to boost service center effectiveness and capacity while creating an effective and robust Agile incident management process.

Implementation can also enable these internal teams to help solve problems instead of just responding to them. Additionally, external service or call centers can transform from net negative to net positive in terms of revenue generation. Alongside the external benefit, we see employee satisfaction and an expanded ability to drive value beyond the realm of direct support.

This case study lays out a proven five-step process to systematically implement Scrum in a specific call center. This process, and the results, have been replicated in other service centers as well. These steps are listed sequentially. But, like Scrum itself, they can be rolled out organically, allowing for these changes to be made one at a time and iterated on or all at once.

Step 1 – Tickets: A Problem of Priorities

Nothing defines a call center as much as the tickets. Just how many tickets a facility can process in a set period of time is often a metric of success. When done right, each ticket represents a customer, a problem, and eventually indicates if a solution was found or more work is needed.

All of this is why Dr. Jeff Sutherland, co-creator of Scrum, and founder of Scrum Inc. says when working with a call center “I always start with the tickets”. He often finds the same two problems: A lack of business prioritization and missing information.

Both were on display when Sutherland was brought in to help a customer support center at Intronis, a leading provider of online backup services. The call center was receiving twice as many calls as they could handle. “My first question,” Sutherland states was, “tell me about your tickets. Are they prioritized properly?”

The answer was “first-in, first-out.”

So Sutherland asked, “Is that going to make the company the most revenue?”

The support team answered “no.”

This is an important realization, albeit a counterintuitive one. But it shouldn’t be. Especially when you factor in the 80/20 rule laid out in the Pareto Principle.

In this context, Pareto plays out in two ways;

Roughly 80% of business value comes from 20% of service or call center customers. This is true whether the tickets are generated internally or by public users. In any other business case, high-value customers receive preferential treatment. Service centers should be no different.

Roughly 80% of support requests are generated by just 20% of customers. This means service center capacity is devoured by relatively trivial requests – thus creating a bottleneck for serious customer support needs that can and will affect an organization’s bottom line.

The first-in, first-out workflow may seem more egalitarian. But, as Sutherland notes, it comes at a high cost. “When important customers are made to wait as long as everyone else it reduces revenue, impacts sales, and slows everything down.” He adds that “Even CEO’s get caught” in this first-in, first-out trap. So the question isn’t should tickets be prioritized by business value, the question is who prioritizes them and how.

Enter the Product Owner, one of three roles in Scrum.

The Product Owner is accountable for knowing the relative business value of customer wants and needs. And for prioritizing a backlog based on that knowledge.

A successful Product Owner of a service center team sets clear guidelines for prioritization. These guidelines are fully explained and shared with the Scrum Team during Scrum Events and through both the Product Backlog and Sprint Backlog.

At the Intronis call center, Sutherland asked: “who’s going to be the Product Owner?” The Chief Operating Officer volunteered. They knew the relative business value of the customers and saw what proper prioritization meant for the customer, the service center, and the company.

Step 2 – Tickets: Key Information

Prioritized tickets alone will boost key customer satisfaction. But if you don’t boost the throughput, non-prioritized customers are left waiting and unhappy. An Agile customer service center will see it’s productivity and capacity jump so that all tickets, prioritized or not, are dealt with efficiently and satisfactorily.

At Intronis, Jeff Sutherland’s second set of questions focused on the tickets themselves. What they contained and what they lacked. What he found was that many of the tickets were incomplete. “Somebody would pick up a ticket and say we can’t work on this because we need ‘X’ from the customer.” Emails would then be exchanged. Calls held. The needed information was finally collected.

But these extra steps meant tickets took longer, and fewer were processed.  Which frustrated customers and team members alike.

So Sutherland worked with the Scrum Team to create a ‘Definition of Ready’ – an established set of information needed for the team to begin work on the tickets immediately. Establishing a ‘Definition of Ready’ which was clear to both the Scrum Team and the customer doubled call center capacity. “After two weeks of implementation of this definition of ready, the team went from doing one-thousand tickets a week to 2-thousand tickets per week.” They were able to double their output.

Similar results were soon seen at Intronis.

Step 3 – Value Stream Mapping and Scrumming the Process

Scrum is known for fostering innovation not only products and services but the process that delivers them. This is how Scrum Teams become hyper-productive and achieve twice the work in half the time or better. Scrum Masters are accountable for this continual process improvement. They help the Scrum Team remove impediments, identify and clear bottlenecks and dependencies. Scrum Masters also surface any problem slowing the team down that they alone can’t overcome.

At Intronis, Sutherland used value stream mapping, a common Lean technique used by Scrum Master to identify bottlenecks and impediments. He began by asking them “what happens when you begin work on a ticket?”

The team laid out the following system. “We get a call from a customer which usually takes about five-minutes. Then we usually can’t solve the customer’s problem without talking to the Head of Support.”

It usually took about two hours for the Head of Support to respond. Here was the first bottleneck.

Only after that could the Scrum Team Member working the ticket finish the process with another five-minute call to the customer.

Armed with this data, Sutherland asked the Head of Support if he could provide a faster turnaround. “Yes,” he replied, “if it’s important, I can average 10-minute turnaround time.”

It was important.

The increase in process efficiency alone could double their throughput. Here’s how Sutherland explained it. “Your original process efficiency is less than 10%” But if he could deliver on that 10-minute turnaround, the process efficiency would jump dramatically. “That’s a process efficiency of 50%. Now,” he added, “you’ve got a highly tuned Lean operation.”

Step 4 – The Interrupt Pattern

Another key process improvement came with the unique workflow of a service center in mind. The vast majority of their daily work was unknowable and therefore hard to plan for. Hard, but not impossible.

So Sutherland advised them to use a Sprint Backlog that accounted for this. 90% of their capacity would be allocated in an “Interrupt Buffer”; a method of allowing emergent work, in this case, tickets, to be brought into the Sprint and worked on as it came in.  This allows the flexibility and responsiveness service centers need to utilize an Agile customer service model and boost customer satisfaction.

The other 10% of the Sprint Backlog would focus on process improvements. These ranged from the use of a Kaizen, an experiment to see if a specific change in process will boost productivity, efficiency, Scrum Team happiness, etc. to the creation of a timeline tracking surges in support requests so the Scrum Team could help do root cause analysis. At Intronis, Sutherland says, this led to a weekly “brown bag lunch where developers and support teams talked through serious platform problems and figured out how to fix them,” and how to prevent similar problems in the future.

And as process efficiency rises and the team’s velocity increases, that buffer will shrink. This allows for the service center to expand to upselling current clients or to proactively call them to ask if there was anything they could do to help them that day.

Step 5 – Using the Scrum Events at Call Centers

Each of the five Scrum events plays an important role in any implementation. Here is how they work together at a service center.

The Sprint: These are kept as short as feasible. No more than one week in length in many instances following a Monday-Friday cadence. This allows for quick inspection and adaptation on process improvements while allowing for the bulk of work to be focused on customer requests and customer service.

Sprint Planning: This event replaced a regular Monday morning meeting. Scrum-ifying it made the meeting more efficient, effective, and shorter. The Scrum Team made sure the Product Backlog was ready and that everyone was clear on the process improvement(s) they were working on this Sprint.

Daily Scrum: The Scrum Team used these events to align on the Sprint Goal, with 10% of their backlog dedicated to process improvement and replan the Sprint Backlog as required by workflow. This boosted both effectiveness and communication saturation.

Sprint Retrospective: This event was held on Friday afternoons. The service center Scrum Teams used the happiness metric to get data on how everyone feels about the company, their job, and process improvements that would make them feel better. The Retrospective was kept short since it was mainly used to prioritize the process improvements and identifying the top priority items to go into the Backlog for the next week along with acceptance tests.

Sprint Review: Here, the Scrum Team analyzed the work accomplished for the week, noted any surges in ticket volume for future root cause analysis, and evaluated the process improvement experiment(s) undertaken during the sprint.

Outcomes

Before going Agile and implementing Scrum, the call center at Intronis was getting twice as many customer calls as they could handle. Six months after rolling out Scrum, their call handling capacity had jumped by 400%.

The call center Scrum teams had enough excess capacity to enable them to become a second sales force. Customer satisfaction data soared as the team proactively reached customers before being contacted themselves.  Additionally, the Scrum Team members reported being happier and more engaged.

Whether you call them call centers, help desks, service or support centers, these groups play a critical role in many organizations. When they go Agile and use Scrum, they change the game.

Better Results. Starting Now.

From Fortune 100 companies to the newest of start-ups, Scrum Inc. transforms companies into Agile enterprises. Schedule a consultation by filling out the form below or call us at 617-225-4326.