KU Education

In the Kanban Coaching Professional Masterclass, I teach coaches and those leading Kanban initiatives how to assess the appropriateness of the Kanban Method and the appropriateness of applying a kanban system within an organization. This is the first of a series of blog posts on appropriateness and getting started with an enterprise scale Kanban initiative.

 Appropriateness of Using a Kanban System

When should we use a kanban pull system? Firstly, we should realize that we apply kanban systems to a service delivery workflow. Assuming we have identified a workflow and can describe the types of work it processes and the service interface and service levels it offers then we have a good candidate for a kanban system. Early examples included IT system software maintenance and sustained (or business as usual) engineering. This is classic example of an IT service within most large corporates. So we have a service delivery workflow but why would we choose to use a kanban system with such a workflow?

There are various reasons for choosing a kanban system. Any or all of these might be true and would represent an appropriate choice:

1. Deferred commitment is desirable – because early commitment is causing excessive re-work and wasted effort
2. There is unnevenness in the flow of work – and we want smooth, even flow
3. The workflow system (and its workers) are overburdened – and we wish to relieve this

Let’s look at each of these in turn and learn how to recognize them

Deferred Commitment is Desirable

We prefer to defer commitment on specific work items to be processed through a service delivery workflow if the future is uncertain and our opinion on what is important and timely is likely to change. Similarly if priorities keep changing and we are continually re-planning and communicating new delivery dates and new sequencing for items to be processed in through the service, we would prefer to defer commitment and reduce our planning and prioritization overhead. If we do this properly, we can reduce waste in this area to almost zero. We would also prefer to defer commitment if we have a high abondonment rate – ideas that are never started and always depioritized – or a high discard rate – ideas that we actively discard as of low value, low return on investment, or low priority. Equally, if we have a high abort rate after commitment where we actively cancel items that had been requested and confirmed, or if we have a high level of completed work which is delivered by never used or not actively commissioned for use in the field. All of this indicates that we have a habit of committing early to things for which we are not certain we really want to take delivery. This is a strong indicator that we wish to defer commitment. Kanban systems enable us to defer commitment and would be an appropriate choice. In summary, deferred commitment is desirable when

• the future is uncertain
• things might change
• priorities are often changing
• replanning is common and frequent
• there is a high abandonment rate for incoming requests
• there is a high discard rate for incoming requests
• there is a high abort rate for committed requests where work already started
• there is a high level of delivered work which is ignored, never used or never commissioned for use in the field

Unnevenness in the Flow of Work

Typically unnevenness in the flow of work affects our predictability or has a tendency to overburden workers then leave them idle for periods of time. If we value predictability or we value evenly loaded workers who work to produce good quality then we wish to smooth the flow of work through the service. Unnevenness in flow can be caused by large batch transfers, by arrival of unplanned work in an unpredictable fashion, or by blocking issues which prevent work from being completed. Unplanned work is often of a speculative nature and often comes with a desire for a high class of service. This results in planned work being set aside in order to service the unplanned, speculative work. Requests for information such as estimates for future work are typical of unplanned, unpredictable, speculative demand. The arrival of this work prevents planned and committed work from being delivered in a timely manner and within customer expectations and service level agreements.

In summary, unnevenness in flow is caused by

• large batch transfers
• unplanned, speculative, disruptive work requests
• blocking issues

Overburdening

It is common in creative and knowledge worker industries for workers to be constantly overburdened with too many requests and too much work-in-progress. The results of this lead to stressed workers, poor quality and long and unpredictable lead times. If we desire good quality, short lead times and predictable delivery then we need to relieve the workers from overburdening. This is simply achieved with a WIP limit. Kanban systems are good solutions for relieving overburdening.

In summary, overburdening can be observed by

• long queues of requests waiting to be serviced
• too much work-in-progress
• too much multi-tasking and task switching
• stressed workers
• poor quality
• long and unpredictable lead times

Summary

Kanban systems are an appropriate choice for improving service delivery when there is a need for greater predictability in delivery times, higher quality in deliverables, deferred commitment would reduce waste and re-work in planning and prioritization, there is a need to smooth the flow of work through the service, the system (and its workers) are overburdened leading to poor quality and long, unpredictable delivery times.

The use of kanban systems can: save money by reducing wasteful upstream activities such as planning and prioritization; improve ultilization by smoothing the flow of work; improve service delivery by improving quality, predictability and time to delivery.

For a corporation setting out on a large scale Kanban implementation, there is the inevitable question of, where to start? Typically, clients want to run a pilot on a single service delivery workflow but which one to choose? Firstly, we must find a service delivery workflow that is appropriate for a kanban system. [See the first post in this series on appropriateness of kanban systems]. To do this, we might view the organization through The Kanban Lens in order to identify suitable services. Secondly, we must assess whether this service is a good choice for a place to start Kanban.

 Goals for a pilot kanban system

Assuming we hope to implement the Modern Management Framework widely across our enterprise and across many creative or knowledge worker services in our business, then we want our initial kanban system pilot to be successful, to be permission giving for others, to inspire and motivate further change and to catalyze a viral spread of Kanban throughout our business. In order to achieve these goals we must be careful where we choose to start.

This flip chart shows our guidance on where to start with Kanban initiative. Let’s look at each of these in turn…

Must be highly visible

If we wish a pilot project to be inspirational, to cause a viral spread, to be permission giving for others, then they have to be able to see it. Typically, we advise that initial pilots should be in services provided in the headquarters or main corporate campus. We do not advise that the pilot is run at a satellite office as this is unlikely to meet our goals of being permission giving for others. There are some exceptions to this. If we pick a service within a product range that is core to the identity of a business, for example a platform development unit such as core layer in telecom infrastructure where the firm makes telephone switching equipment and being in that business is core to its identity, then regardless of the geographic location then the outcome is likely to be permission giving to other product units within the enterprise.

Connectedness

An aspect of visibility and ability to be permission giving or catalyze viral spread is whether the service is connected to others or not. Ideally, we don’t want to start with an isolated pilot. We want to choose a service that actually has dependencies on others or services others which are dependent on it, or both. The reason for this is that we want other services to feel the effects of implementing this first kanban system. We want the pilot system to perturb the wider system of systems, our ecosystem of interdependent services within our enterprise.

Must not be mission critical

Executive tolerance is greater when changes are being made to services that are not considered mission critical, therefore we will get more time and latitude to make change if we pick an area that isn’t mission critical. The J-curve effect can be larger when we pick a non-mission critical service as a starting point. Our goal will be to be successful and as a result gain more executive tolerance before we try to apply similar changes to a mission critical part of the business.

The Intersection

At first, the sets “highly visible” and “not mission critical” sound like they are mutually exclusive. However, it appears that maintenance work on mission critical systems is often viewed as not mission critical. However, because it is a mission critical system, any upgrades and enhancements deployed have a high level of visibility. Hence, the maintenance group for a mission critical system is actually a highly visible part of the business. It is perhaps no accident that all the early Kanban implementations were on IT systems maintenance in large firms such as Microsoft and Robert Bosch.

Management motivation

Early Kanban implementations fell into the first category – in so much pain, no one cared what was tried. Simply put when current service delivery is so poor there is a desire for change, any kind of change so long as someone is willing to show leadership and make it happen. However, we may choose to start in a part of our business where the local management is enthusiastic about Kanban, the Modern Management Framework or things which inspired them such as Lean, Theory of Constraints, or Agile methods. There is one other circumstance where we may choose to start: an area of the business where senior management wishes to actively shift cost, risk or investment. This third category requires a truly deep implementation of the Kanban Method and hence the J-curve will be larger. We would only pursuse this if other circumstances were suitable such as strong executive tolerance and a high level of organizational maturity. We need these things in order to buy enough time and understanding to allow our deeper changes to take hold.

Scaling Out

As our pilot kanban system shows success we want to start scaling out Kanban across the enterprise. Typically, we would look to “kanbanize” dependent services and those connected to our initial pilot until we’ve completed the roll-out across an entire business unit. We’d then repeat the process in other business units until the entire enterprise is running on Kanban.

Soft Targets

Obvious places to start with Kanban are existing shared services within an organization. These can be simple places to get started. Some shared services, such as enterprise architecture, database administration, code security and so forth, can be so simple that the resultant kanban systems are degenerate forms such as personal kanban or team kanban. They typically have no real workflow and result is visualizations that show To Do | Doing | Done three column boards. While these are not bad they are typically not permission giving examples for wider service delivery workflows with multiple activities and handoffs between different groups of specialist workers.