How Does Kanban Support Service Management Agility?

Elsewhere, I have proposed a Manifesto for Service Management Agility, describing what agility in managing services would be. Kanban is well known as a method for Agile project management. So let me put these two concepts together. How does Kanban support service management agility? How can agile service managers make good use of Kanban?

A Manifesto for Service Management Agility

Agile practitioners usually think of agility in terms of the Manifesto for Agile Software Development. But surely each work discipline has particularities that distinguish it from software development. Let’s try to understand in more detail agility in the management of services. Let’s start by comparing the agile software development manifesto to the proposed manifesto for service management agility:

How does Kanban support each of these five propositions? I will examine the first three propositions in this article and complete the analysis in a future article.

Emotional Intelligence over Detailed Processes

In “traditional” service management frameworks, heavy emphasis is placed on defining management processes and assigning unambiguous responsibilities for each process role. These frameworks are implicitly Tayloristic in nature. They assume that a given type of work can be optimized using a single process. They assume that the process actors can perfect the execution of their tasks, as defined by the process.

When it comes to managing services, the reality is quite different. With a few exceptions, most service work is highly variable. In most cases, it is not possible to perform work, in the same way, each time, due to variations in the timing and cadence of work, the availability of resources and the nature of the services themselves.

How are the various service management disciplines highly variable? Variability should be obvious with such disciplines as problem management. Every problem is itself somewhat different.

Customers make service requests, each of which tends to have its own characteristics. That being said, some service requests can be standardized and even automated, but these are the exceptions that prove the rule.

The situation is similar with changes. With the exception of standard changes, no two service changes are alike. And so on for virtually all the service management disciplines.

Let me contrast now the rigid, Tayloristic approach with an Agile approach using Kanban. I once had a client that had defined 87 distinct processes to be used in the context of managing the end user’s workplace.

Unfortunately, even that high level of complexity and detail did not cover 100% of the management cases. Furthermore, it was completely unrealistic to imagine that the responsible personnel would learn and apply all 87 processes. Finally, the maintenance of those 87 documents was a valueless burden.

So here was a case where an organization tried to define every aspect of managing services, down to the most insignificant details. But those 87 processes were far too numerous and far too detailed.

It turns out that all the work could be performed by an intelligent application of four distinct work patterns. This far simpler approach required the various specialists to collaborate in a flexible way. It also required the specialists to remain sensitive to the particular situation and needs of the customers.

In short, the more emotional intelligence the specialists can show, the quicker they can adapt to the needs of a specific case, the faster they resolve the case successfully, and the greater the satisfaction of the customer with the services delivered.

Kanban is well-suited to supporting this agile approach capitalizing on emotional intelligence. First, Kanban generally uses very simple value streams. In contrast, traditional service management tends to use detailed and inflexible processes. Such processes focus on the technical accomplishment of tasks rather than on maximizing the value that customers can obtain from the work.

Furthermore, Kanban provides a framework for identifying the particular cases where work is blocked and where agile collaboration is of particular importance in unblocking the work and advancing cheerfully to resolution.

Good emotional intelligence increases the ability of team members to identify blocking issues that a colleague might hesitate to articulate. Emotional intelligence is manifested in the readiness of team members to act to unblock work. In addition, it helps to maintain the energy levels and clarity of vision that encourages a team to deliver with celerity its output to the customers.

Services Fit for Purpose and for Use over Meeting Specifications

Stating that a service is fit for purpose and fit for use has a particular connotation in the service management world. Being fit for purpose means that the service either:

• creates output that enhances the customer’s performance; or
• enables the relaxation of constraints on the customer.

Being fit for use means the service has attributes appropriate for the targeted service consumers, such as its level of availability, its capacity, its security, and more. Security is particularly important in services that handle sensitive data or require secure access, such as financial services, healthcare, or government agencies. One way to enhance the security of a service is by using a Virtual Private Network (VPN). By incorporating VPNs into their service management strategy, organizations can ensure that their services are secure and meet the security needs of their customers. A customer can obtain value from a service because it is both fit for purpose and fit for use.

A service provider attempts to specify service offerings that match the needs of the customers they target. But, given the high degree of variability of those needs and of the contexts in which services are requested, it is highly unlikely that the service specifications can describe all possible cases.

So what should a service provider do? Should it refuse requests for service that do not match the exact specifications of the offering or should it attempt to provide services that help customers obtain the value they seek, even if that means adapting the way in which the service is being provided?

There is no single answer to that question. Each service provider will have their own strategies. However, the agile service provider will value understanding the customer’s goals in using the service over providing exactly the service defined, neither more nor less.

As a result, the agile service manager is more concerned with making a given service act fit for purpose and for use, rather than simply relying on execution according to the defined process.

Once again, Kanban meshes well with this agile approach. We already saw in the previous proposition that we do not expect to use a kanban board with dozens (or even hundreds!) of distinct value streams.

We expect, instead, that the main phases of work will be defined on the board with a level of detail that might depend on the degree to which the work is obvious, complicated, complex or chaotic (as defined in the Cynefin framework).

Using a kanban board helps to emphasize the need to do work that provides value for the service consumer. This is in striking contrast to the detailed workflow tools that characterize traditional service management or business process management.

By structuring work around a high-level value stream, Kanban gives the service provider the flexibility to adapt work to make the service fit for the customer’s specific and highly variable purpose and use.

In short, the question for the rigid practitioner using traditional tools is, “Am I performing the prescribed task according to the prescribed service levels?”. The question for the agile service manager using Kanban is, “Am I helping the flow of work advance toward delivering the output that provides value to our customers?”

Flexible Engagement over Fixed Agreements

In a service management context using traditional tools, work is pushed from task to task based on a set of agreements. So-called “best service management practice” puts heavy pressure on service providers to negotiate service level agreements with their customers. The internal relations among service provider teams are governed by a set of “operational level agreements.” Finally, legal contracts govern the performance of third-party suppliers and their obligations to the service provider.

It is almost impossible to ensure the overall coherence of such agreements when it comes to meeting customer expectations. Even worse, “best practice” advises that work should be prioritized based on two factors: the impact on the customers of the events being managed and the urgency with which that work shall be done.

In most cases that I have ever seen, priority is determined by nice-looking, symmetric matrices of impact and urgency, rather than via any real attempt to manage the risks of work and its value to customers. Here is a typical example of task priority, based on impact and urgency:

In many cases, organizations relate task priority to service levels, in particular, to a predefined lead time for a task. The result of such an approach based on fixed agreements is that work is pushed, ordered and measured based on its conformity with somewhat arbitrarily defined priorities, rather than based on how soon the customer can obtain value from the work.

“Flexible engagement” refers to the concept in Kanban where a team engages to execute work based on its capacity to perform rather than based on pre-negotiated agreements. Thus, work is pulled by a team according to its WIP limits and according to the Kanban classes of service of the work.

How does this differ from the “best practice” approach? First of all, the importance of the impact of work on customers is minimized, because work items are defined so as to be small and incremental. Few individual work items (except the resolution of certain incidents) are likely to be high-impact items.

Secondly, Kanban emphasizes the overall value of work to customers. Now, there is nothing in traditional service management that prevents this type of work assessment.

But in practice, organizations rely on vague proxy metrics for value rather than focusing on the value itself. Thus, tasks that impact 100 workers are considered to have a higher impact than tasks that impact only a handful of workers. Maybe yes, maybe no.

Finally, traditional practices ignore the idea of class of service. For example, a work item might be in a fixed date class, where the deadline is relatively far in the future, but the value of the work for the customer might be very high.

According to the Kanban rules of engagement, such work might be deliberately put off in favor of lower-value work items that might be of the intangible or the standard class.

In short, Kanban foresees a set of principles used to prioritize work and decide when to engage in its performance. These principles should be applied in an agile way rather than pushing work based on a set of priorities defined in a complex system of agreements.

Planning for Change Over Following a Plan

In a deterministic management system, many types of variations during operations are viewed as undesirable events, failures in execution, or failures in planning. Hence, they are considered to be problems that should be rooted out.

They prevent the organization from following its plans. In a probabilistic management approach, such as Kanban, variation is recognized as a fact of life that must be taken into account in the working methods.

The degree to which variation occurs will depend very much on the nature of the work being performed and the work system being used. If we think in terms of the Cynefin framework, the more a system is distanced from the obvious and approaches the complex or the chaotic, the more variation can be expected. These variations are of many types:

• When work is requested
• Who requests work
• The accuracy, completeness and availability of the inputs to work
• The nature of the work itself
• The experience of the service provider with the type of work
• The availability of resources to perform work
• The types of quantity of work already being performed
• The specific outputs required from the work

In a deterministic system, considerable efforts are invested in limiting variability. The identities of those who are allowed to request work may be strictly regulated and subject to contractual agreements. Systems are established to capture specifications for work carefully.

The nature of the work items accepted might be strictly limited. The work itself is supposed to be performed only according to well-established procedures. The start of work and the delivery date are planned when the work is accepted.

When using Kanban, most of these constraints to performing work are removed, making the entire system much more agile. Instead of worrying about the failure to execute according to a predetermined plan, Kanban accepts that there will be unexpected variations. It flexibly takes those variations into account by:

• Committing to new work items according to circumstances rather than according to obligations created upstream
• Selecting the next items on which to work according to changing circumstances rather than according to a predefined plan
• Ad hoc unblocking work that is taking too long

I once worked on a project initially designed to change the desktop operating system in a company (70’000 workers and 100’000 machines).

Unfortunately, the scope of the project grew exponentially, based on the logic, “As long as we are changing the operating system, it would make sense to also change the productivity software, and change the tools used for releasing that software, add application virtualization and streaming, change the global support structure” and so on and so forth.

The project had a program manager, two assistants, 8 project managers and a good chunk of the project management office to handle the heavy burden of planning and administration.

After five years (!), the new desktop started to be rolled out, following a major mid-stream change to a new target version of the operating system and many other events causing waste, rework and delays. What is worse, no lessons were learned for how to avoid such complexity and waste for the next such change.

Using the Kanban method, the work would have been broken down into much smaller components that could be released independently. And as each component would be released, the circumstances would inevitably be changed.

Rather than being held hostage by incomplete and overly optimistic plans made in the past, Kanban allows an organization to get the value of work incrementally and much more quickly, with much less waste.

Another example of planning for change would be in disaster recovery plans. It is virtually impossible to plan in advance all the events and circumstances during a catastrophic loss of services. Trying to plan in advance what might happen and how you ought to respond to those events is not likely to be a fruitful effort.

Kanban, on the other hand, provides a good compromise between allowing the flexibility to respond to events as they occur and to the discovery of new information and having sufficient structure to ensure that key activities are not forgotten.

The kanban board gives excellent visibility of the handling of unfolding events while minimizing the effort required to keep stakeholders informed. Many traditional service managers view poor performance as the result of a lack of planning. Many service managers using Kanban view poor performance as the result of 1) wasting too much time on controlling plans and 2) doggedly trying to follow plans when changed circumstances have rendered those plans obsolete. Thus, Kanban is an agile method that plans for the fact of all sorts of variation in work. As a result, it radically reduces the effort required to fix things when unexpected variation appears to have broken them.

Distributed Decision-Making Authority Over Immediate Reduction in Direct Costs

The issue here revolves around the question of how an organization makes decisions and where the information needed to make good decisions is available. Kanban board authority requires an investment in employee development and in information systems that do not usually have quick and demonstrable paybacks. Consequently, these sorts of investments risk being among the first cost cuts.

That being said, investing in distributed decision-making is likely to have a far greater effect on reducing costs than quick and dirty budget cuts. It also contributes directly to agility by reducing the amount of time required to make decisions, improving the quality of those decisions, getting approvals, and resolving customers' needs.

Increasing the quality of decisions reduces, at the same time, the need to diagnose and fix mistakes. It helps reduce the costs related to rework and increases customer satisfaction.

When services are being delivered directly to customers, there is a particular interest in ensuring that the front-line service provider has both the necessary information and decision-making authority to ensure the satisfaction of the customer while keeping the costs low.

Unlike such activities as product development, where products undergo various activities—such as planning, analysis, development, and testing—customer-facing service acts are generally not mediated. The customer does not want to hear, “Let me get back to you about that.”

The customer wants the right answer or the right action now. And yet, many of the traditional cost-cutting activities in service management lead directly to this sort of problem.

For example, I worked with a banking organization having a very highly reputed help desk. Its personnel received extensive training and had access to sophisticated tools providing the information they needed to resolve a very high percentage of support cases at the first line of support, if not on the first call.

In spite of this high performance, which was highly appreciated by the bank’s employees, it was decided to reduce support costs and hire poorly paid help desk agents, often outsourced to third parties, who had a high level of turnover.

Not having the same experience as before, they never achieved the same levels of first-call resolution, and customer satisfaction dropped.

The resulting increase in hand-offs to a second and third line of support resulted in much slower resolution times, ping-ponging of assignments, and all the wastes or waiting, errors, and redoing work associated with push systems of flow.

Distributed decision-making authority is precisely the sort of responsibility that Kanban allocates to front-line teams. This is particularly the case for making commitments to work and the decisions as to which work item to execute next.

Kanban is thus part of the culture of making teams more autonomous and encouraging the people who have the information about a situation to make the decisions about how to handle that situation.

At the same time, distributed decision-making increases organizational agility because it avoids the waiting associated with handoffs, the problem of front-line personnel having to mediate between the customer and the decision-maker and the waste of rework when erroneous communications lead to poor decisions.

Conclusion

Service management practitioners find themselves increasingly in one of two camps. Some believe that good service management is a matter of perfecting the use of practice frameworks such as ITIL® or SIAM®. Others believe that for services to be well managed, the service provider should embed agility in its organization and its methods.

For this latter group, the proposed Manifesto for Service Management Agility outlines what it means for a service provider to be agile. But that manifesto deliberately describes service management agility at a high level. It remains for a service provider to adopt specific methods and tools.

In this article, I have reviewed how Kanban supports agility in managing services. Kanban is, in my view, the agilest of the common methods in use today. It is, as we have seen, an excellent fit for the values and goals of service management agility. Service managers should look beyond the other agile frameworks and seriously consider adopting the Kanban method for delivering and supporting services.