service management agility with kanban part 2

This is a sequel to the first guest post of Robert Falkowitz on the Kanbanize blog. Some of the information inside this article may be confusing if you haven’t read How Does Kanban Support Service Management Agility? To get the most value out of this post, please take the time to get familiar with Part 1.

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 who is allowed to request work may be strictly regulated and subject to contractual agreements. Systems are established to carefully capture specifications for work.

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 is 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

service management agility - plan

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 turns 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 costs 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, to improve the quality of those decisions, to get approvals,  and resolve 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 that 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 and lacking they never achieved to 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.

service management agility cutting costs

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.


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.

Try Kanbanize for Free

About the author

Robert Falkowitz is a professional Lean coach, developer of Kanban foundation courses, and a certified service management consultant.