Kanban adoption-Lessons learned

A client of mine asked for a list of lessons learned while applying kanban, so rather than writing it up and send it off in the mail, I thought it would post it here for everyone to enjoy.

I should add that all these lessons were actually learned, and that we made every one of these mistakes at some point and had to learn the hard way not to do it again :-).

Introducing Kanban at the same time as other major structural changes.
While Kanban is positioned as a change management and change catalyst framework, effectively using Kanban does require a (sometimes extreme) shift in thinking. Our experience has been that Kanban should be adopted on top of a working system already familiar to staff and management.

The introduction of a Kanban toolset could be coupled with other big changes, for instance, institutionalizing brand-new capability. The risk however, is that these "big changes" foster resistance often found with change management initiatives. This can cause staff and management to resist the Kanban is it becomes directly associated with these changes.

Detailed, upfront analysis of process components
There is a tendency for many organizations to engage in detailed design activities to get an understanding of demand, work types, and supporting processes & policies. There is a desire to start with a nearly perfect Kanban system.

Our experience again shows that there is a fairly steep slope in terms of the law of diminishing return when it comes to upfront analysis. Kanban systems can be effectively set up with a minimum amount of upfront work, and progressively refined over the first 1-2 months of adoption. As these systems are easy to refine, it is better to get started sooner with imperfect information.

Ensure that Kanban systems reflect work as it actually is completed by management & staff
There is a desire to try to "fix" processes while modeling them to prepare for a Kanban implementation. This should be avoided; we want to avoid the possibility of "shadow" processes, where the official approach deviates from what is actually going on in the organization. We also want to avoid designing a future state solution unless performance can be measured against the current state, this requires that can then be set up to reflect the current state.

Avoid enforcing changing work conditions in a desire to create the optimal Kanban system
Associating changes to the work environment (such as co-location where did not exist) to support a Kanban system can foster resistance to the approach, and is counter to the Kanban method. As much as it is practically possible, existing conditions of work should be respected. Rather than trying to change the environments of work to support a Kanban pilot, is recommended to select a pilot where more favorable work conditions already exist.

Start out with Low inventory levels and raise them if you need to
The amount of inventory that a particular system is allowed to consume is inversely correlated with the amount of change you want to introduce to that system of work. Starting with a large inventory level is a natural choice for those who want to follow a conservative approach to change.

That being said or experience suggests that Kanban systems with high amounts of inventory tend to completely obscure early identification of bottlenecks, blocking issues and other problems. Larger inventory systems are also hard to maintain and manage, causing workers to abandon the Kanban approach completely.

An approach that we have found to be more successful is to start with a lower WIP level, such as 1-1.5 unit of inventory per knowledge worker. This causes bottlenecks to form extremely quickly, making it clear where opportunities for improvements exist. Instead of immediately tackling these bottlenecks, which can be challenging for lower maturity organizations, make it clear that the team can raise inventory levels as necessary to avoid immediately tackling these bottlenecks as they form. This will allow the team to take note of every time they have to raise inventory level, this is a potential opportunity to improve when the team has the capacity to do so. This strategy allows more conservative teams to get better visibility into the nature of existing improvement opportunities without having to tackle these issues early on in the Kanban adoption process.

Expand scope of Kanban boards to reflect all work being completed by staff for a specific capability
A typical use case for Kanban adoption is to use Kanban to support the work of one project. Very early on, it is discovered that a significant portion of the work being assigned to various project members are actually not part of the project being represented by the Kanban system. Work is often blocked simply because an individual is doing non-project related work.
Our experience shows that project focused Kanban's have limited usefulness unless the projects are supported by dedicated workers. In most cases we have found that Kanban boards should be used to represent the work of multiple projects and scoped by specific business objectives and/or technical capabilities. One of the main benefits of the Kanban system is to support the allocation of specific workers across numerous priorities in real time, and to dynamically manage risk and value of delivery.

Keep metrics extremely simple until the board stabilizes
A major benefit of the Kanban system is the incredible wealth of data that can be shared across management and staff. There are major pitfalls in starting with the complete gamut of metrics from the start.

Most Kanban systems will undergo major revisions in the first 1-2 months. Supporting a Kanban system with detailed process specific metrics (e.g. cycle time of requirements, throughput of design, etc.) will mean that every time this Kanban system changes the supporting metrics framework will need to changed as well. This causes a lot of rework. Furthermore, as the Kanban system changes the units of measurement need to change as well, new work ticket types are created, and others are modified or removed.

Kanban systems need to be incredibly responsive to change during their first couple of months of use, and performance needs to be stabilized before metrics have any meaningful value. The exception to this would be capturing overall lead time and throughput, as these metrics are largely tolerant of change of the internal system workings.

Supplement operational reviews with retrospectives
Operational reviews provide a wealth of insight on how to improve delivery capability. That being said, they can take time to set up properly. Systems of work need to be stable, and maturity needs to exist to take the time to review system performance, analyze it, and aggregated into one or more meaningful reports.

In the interim, teams needed explicit opportunity to reflect on their own performance, as well as their journey to better productivity using a Kanban approach. We strongly believe that supplementing larger, organizationally oriented operational reviews with more frequent, team oriented retrospectives is critical towards helping teams get into a culture of thoughtfully improving the way they work. We recommend retrospectives be conducted monthly or biweekly, using whatever metrics are available depending on the maturity of the team using Kanban.

Identify an internal champion as soon as possible
Not having a "prime" consumer for any change initiative is risky. We are seeing numerous clients attempt to start Kanban pilots/Kanban initiatives without selecting an appropriate champion to continue the work once external coaches have discontinued their services. Finding an appropriate champion can be very challenging, this person needs to be passionate about improvement, and be able to motivate others to think about things differently.

Don’t over engineer the board
Kanban, like all other systems suffers from the fact that the system is often designed and built by engineers. Engineers are often attracted to complexity, and like to make sure that their work can handle all of the edge cases. Our experience shows that this can result in an over engineered board, with too many swim lanes, work types, three-tier/4 tier work tickets, and overall complexity that makes tracking and maintaining the board extremely challenging.

Kanban systems do not need to visualize everything, they are meant to be abstractions of knowledge work that allow instant recognition of how well work is flowing through the system. Understandability is much more important than exact precision.
Don’t treat the Kanban board as a command-and-control system

Project managers familiar with more traditional management approaches often fall into familiar behaviors when interacting with a Kanban system. Work tickets are all affixed with scheduled completion dates, and individual FTEs are held to the fire for any work not making those dates.
This reliance on individual workers accountable for individual activities will foster resistance and interfere with a culture of continual improvement. There will be little motivation to be transparent and visualize the state of all work if any defect or late work is used as an excuse to criticize or punish. Product managers and other leaders need to focus on systemic issues, and how to improve the overall system of work.

Familiarize executives and other stakeholders with the Kanban board and use that to visualize performance
There is often a desire to represent information provided by Kanban system and other simpler forms to make it more consumable to an executive audience. To some extent this is perfectly valid and we recommend working on executive reports. This needs to be balanced with the fact that a Kanban system provides a vast wealth of information that display system health without any need for interpretation. Time should be spent educating executives on how to understand what Kanban systems have to say. Bottlenecks are easy to identify, as are the number of defects blockers and other impediments to productivity