Kanban Adoption Approach

We have been running large transformation projects for the last several years helping organizations to become more agile in their delivery.

A typical approach one often encounters is to select a pilot project, run the pilot and then move onto another pilot.

Based on our experience, we recognize two major issues with the project pilot oriented approach:

1- People already are participating on multiple projects. This causes multitasking that is not captured by the Kanban system. This makes the pilot very limited in terms of value.

2- Organizations often select a project that is just starting. These projects can take as much as 3-6 months to get out of the conception phase. This makes seeing any real momentum impossible.

As a result, we are trying a different approach, one that takes an organization/ team perspective. We hope to eliminate some of the challenges inherent in a project based approach.

We start with a group of early adopters that are working on inflight projects and visualize all of their work.

We are adopting based on “delivery nodes”. We view the organization as a network of interacting units that provide business value. We select a subset of the organization that uses a single technology solution. We get the team onboard with Kanban and try to stabilize their work.

As we are getting an understanding of other work surrounding this delivery node, we can decide who to adopt next. The adjacent node is determined by looking at both risk and value. We want to promote flow for all work under the current scope of adoption while simultaneously expanding our scope.

This approach will allow adoption to proceed using a continuous approach, maximizing flow throughout the organization connecting customers, suppliers, and peers in each subsequent wave.

Implementing basic Kanban throughout the organization allows further insight into the tools/ skills/ methodologies that can be adopted to improve the teams’ capabilities. Additional capabilities, such as feature decomposition and test driven development can be developed as incremental change units and rolled out through the organization where applicable.

We created a roll out plan to have large adoption waves on-boarding 50-60 FTE's per month. After month 2, the basic Kanban implementation is reduced to half to allow the organization to adapt to the new work systems and to start implementing the incremental units of change.

A Kanban board is created to model the rollout plan. The backlog represents the teams that will be trained on the basic Kanban and the incremental units of change.

The adoption wave is a 9 week effort program. Each of the adoption waves will start with a week of Planning & Kick-off and then followed by an 8 week training and coaching program. During the 8 week period there are 6 major learning, workshop and support activities that are essential for a successful implementation.

A Kanban board is developed to model the training material to track the progress of each of the teams through the training program.

We kicked-off training sessions with multiple teams. In a later blog post we will review our initial approach and share our experience on onboarding the teams to their first Kanban board.

Lean Startup For Change: Bootstrapping an Enterprise Kanban Transformation with Lean Startup Methods

By now many are familiar with the concept of the LeanStartup, and the methods pioneered by Eric Ries and others. In a nutshell the LeanStartup approach helps human institutions create value in a sustainable way in highly volatile/uncertain environments. This technique has become the de facto standard for young, savvy technically minded entrepreneurs working in innovative new organizations.

But thinking that the LeanStartup method just applies to the folks in Silicon Valley misses the point of how powerful these techniques are.

Increasingly all manner of organizations, institutions and enterprises are being forced to compete in highly uncertain markets. This means that LeanStartup applies to a wide variety of domains. One such domain is large-scale enterprise transformations.

I have spent the last several years of my career dedicated to IT transformations, helping clients to improve the performance of knowledge workers dedicated to building business applications. I have specialized in using agile and lean techniques, lately putting a real focus on capital K. Kanban, invented and made famous by David J Anderson.

Recently, our team has elected to enhance our transformation approach with LeanStartup. While this is still an evolving approach, I’d like to share our current progress.


Breaking down Change into Increments of Learning
Most change management approaches rely on making a huge number of assumptions about the organization, and impact of specific changes. Kanban provides a more incremental approach to these changes, but still contains a number of assumptions around how people react to certain components of the framework.



























The LeanStartup approach recommends breaking product delivery into a set of Minimum Viable Products (MVP). Each MVP is built for purpose to support learning. The really interesting part of the MVP approach, is that you often don’t have to build anything to learn something about the viability of your product.

In our approach we are breaking up all of the assumptions in our transformation into a set of Minimum Viable Changes, in effect we have decomposed our transformation into the smallest possible units, laid out our underlying assumptions, and then backed up each assumption with a hypothesis and a set of graduated metrics to support that hypothesis.

Defining Target Behaviors Using Measurable Hypotheses
Components of the transformation have to either lead to improved performance (value hypotheses) or facilitate adoption (growth hypotheses). Again rather than relying on assumptions, the transformation vision is decomposed into specific strategies, and the strategies are further broken up into behavioral hypotheses. These hypotheses are tested through the creation and implementation of various MVCs. This approach is allowing us to gather data around whether to change our tactics, while continuing to pursue our overall strategy, or whether to make a major pivot, and make major changes to our overall strategy.



Measuring Specific Hypotheses
MVCs test specific behavioral hypotheses, in our approach we are using classic cohort testing recommended by the LeanStartup approach. Targeting a single MVC against multiple cohorts, or split testing against different cohorts.


We have structured Kanban, and other lean components into a set of graduated behaviors. And then designed appropriate MVC to test these behaviors. We are also currently in the process of extending this framework to cover other agile process components as well.


Here is a sampling of hypothesis with some ideas on how we plan to measure  the accuracy of our assumptions. These metrics are refined depending on the MVC we design to test the hypothesis.


We are only a couple of months into the process, but some interesting observations have already come to light...

• we are adapting ALOT faster, no pivots necessary yet, but we are incrementally adjusting our tactics every couple of days
• our MVCs are getting much smaller, and we are just getting ready to rip down our transformation Kanban board to better reflect the MVC approach as we get more comfortable with it
• cohort testing is revealing a competitive streak with our coaches, causing us to really maximize client participation (one of our key metrics), we are in effect gamifying the transformation

Stay tuned, we will continue to share our progress...

..