Monday, August 1, 2011

Maximizing the Benefits of Kanban as an Accelerator for Lean/Agile Transformations

One of the common approaches to many Lean/Agile Transformations is to start off with a set of "pilots". Typically these are selected based on the likelihood of success, priority and business risk. Often six months or so down the line after a few successful pilots the organization is eager to accelerate the process and attempts a larger scaling initiative to spread adoption. At this point the organization typically hits a wall as they run into a new set of challenges with the new teams/units being "transformed":
  • These teams/units are typically less enthusiastic about the change - pilots are typically "cherry-picked" and are often the most capable and enthusiastic of the change while the rest of the organization is not
  • Larger and more legacy systems/teams bring about different challenges the pilots did not face
  • Limited capacity and budget within the organization to support the larger scale adoption resulting in less time spent with the team/units
  • Executive deadline for the transformation looms closer, typically organizations are looking for organization wide results within a year or two
As a result, the transformation typically starts switching to a "big-bang" type of change as patience starts running out and new challenges to the transformation starts slowing down progress. This where organizations often get into trouble.

As an alternative to the piloting approach is a Kanban change management approach to transformations. The great thing about Kanban is that it allows an organization going through a transformation to adjust the pace of change from fast to slow depending on the tolerance of change within the organization. The only requirement is to ask each team/unit to follow a subset of the Kanban properties:
  1. Visualize what you do today
  2. Limit the amount of work in progress
  3. Improve flow
With the Kanban approach to transformations, the organization can start "transforming" the entire organization on Day 1 without significantly disrupting business as usual while gaining the benefits of scaling out change to a larger group of teams/units. Another way to look at this is from the J-Curve model:

The J-Curve is the amount of disruption/pain an organization goes through when change happens. If you are starting/going through a Lean/Agile Transformation today, this approach is worth considering if you are facing a few of the challenges I discussed.

I'll blog more about the specifics for how we are applying the Kanban change approach in a current large-scale transformation in a later blog post.


  1. Great post. Very congruent with the Marshall Model. Although, the Marshall Model explains my problem with the latter half of your post (incremental change through e.g. Kanban). Yes, one CAN make incremental small changes to improve things, but these small changes often have little success in changing the mindset of the organisation - which ime is a necessity for SUSTAINED transformation.

    - Bob @FlowchainSensei

  2. Bob,

    This post ( and Kanban) doesn't stand alone, Alexis and I use Kanban as more of a change catalyst framework.

    It gathers data, and males outliers amd bottlenecks obvious. Micro changes generated garner significant improvement, and culture does shift thanks to the changes in work.

    We have been complementing Kanban with classical Kotter steps of change, but top down change is informed by Kanban data.

    We call it the gardener model. Plants will do what plants need to do to thrive, and no one can create exact plans for every plant (Kanban), but the overall layout of the garden and the nurturing of the garden can be structured and directed (Kaikku).

  3. "3. Improve flow" gets interesting when the team starts to push against problems that are both outside of their control and likely to be common to multiple teams (i.e. not project-specific).

    I like the idea of having some pre-agreed escalation mechanism for these issues that is visible to transformation team but intended to outlast both it and its pilot projects. It helps to set an expectation for ongoing change and creates opportunities for engagement at multiple levels in the organisation.


  4. I should add that I've seen these issues managed in a Kanban system. Set up by one of your colleagues too!

  5. Absolutely Mike. These are the problems that the team(s) are usually well aware of but is hard to change so they avoid it. By visualizing them through Kanban it becomes something that is hard to ignore. It lines up well with Cotters heart of change by helping everyone "see" and this typically starts invoking emotions, the "feel" part as data highlights the impacts even more. WIP limits act as another catalyst to start solving problems.