Low Flow Efficiency - Resist Temptation to Design Out Waste

Yesterday's post on flow efficiency generated some good questions, comments and stories on the Kanbandev Yahoo! group over night. A question from Tara Santmire prompted me to follow it with this...

Lean Doesn't Have the Answers

Typically Lean consultants, coming to knowledge work, follow a play book that is in my opinion, almost completely wrong. Firstly, they "follow the work" rather than adopting the Lean Product Development technique of "mapping the knowledge discovery" workflow - the series of activities performed to gain new knowledge about what we are doing. I discussed this recently in The Kanban Lens. It's the state changes in the work and not the handoffs between workers that are important in creative knowledge work activities. The second mistake is that having developed their value stream map, by following the work, the Lean consultant will try to design out the "waste" - the non-value-added steps in the workflow.

The problem with looking for "muda" (the non-value-adding waste) and trying to design it out, is that these so called "non-value-adding" steps are performed by humans. The people involved have an emotional attachment to what they do because the practices are often core to their professional identity and their level of competency with the practices is core to determining their social status in a group of peers. Hence, "designing out the waste" meets with emotional resistance. Often in knowledge work, this resistance is passive-aggressive and hard to detect on the surface. My observation on Lean Value Stream Mapping and the "design out the waste" approach to process improvement is that it would work perfectly well with silicon-based life forms but while we are stuck in the 21st Century with carbon-based life forms performing the creative knowledge work, we need to find a better way to improve service delivery.

What Causes Low Efficiency?

Tara asked, "Do you have any insights into why firms can’t get past 40% flow efficiency which you say “is still very good” ? Are there some major types of causes that can be identified?" I repllied that there are three main causes that prevent flow efficiency exceeding 40% in many circumstances...

  1. Dependencies - dependencies on shared services, usually specialists or vendors. Dependencies on different teams or workflows working on dependent pieces of a system or within dependent elements of a product architecture
  2. Common Cause Variation in the Nature of Work - requirements vary, every piece of work is unique and the cycle times through individual stages of knowledge discovery will vary. As a result, some amount of queuing and buffer is inevitable in order to achieve a smooth flow. The alternative is to have significant amounts of idle time for the workers - low utilization - in order to absorb the variability in local cycle times.
  3. Staff Liquidity (or lack thereof) - in a heterogeneous skills and experience environment, matching the right worker to a suitable piece of work means that more work must be in the system. The more heterogeneity in the common cause system, the more WIP is require, hence, the more queuing time (see #2).

To achieve high levels of flow efficiency, you need a very homogeneous workforce - a highly multi-skilled, very experienced team of generalists. You need to avoid handoffs. You need to avoid dependencies in the architecture. You need to avoid regulatory validations and check points. You need to avoid areas of work where the marginal utility of highly talented specialists is the difference between winning or losing, or the difference between being profitably in a business or not being in it at all.

In other words, high flow efficiency is typically only achieved in the ideal conditions for a textbook Agile software development implementation (extreme programming, for example.) Such conditions are not of interest for us with Kanban. I created Kanban to provide an alternative path to improved agility for those with circumstances that did not lend themselves to such ideal conditions. It was no surprise therefore that people in such circumstances were either (a) finding Agile adoption challenging and a poor fit, (b) resisting the adoption, or (c) had already decided "Agile isn't for us."

Engage Workers Emotionally, Let Workflow Evolve

More and more I see the Kanban Method as beyond Lean. Inspired by Toyota's management system, yes, but adapted for use in creative knowledge worker industries where the humans involved are complex carbon-based life forms with emotions. Techniques that appear to work perfectly well in a manufacturing or distribution environment are not effective when "following the work" isn't the appropriate way to view the system.

Kanban engages people emotionally and provides them with the correct levels of feedback mechanisms, the Kanban Kata: daily meetings in front of the board; systems capability reviews (most likely weekly); and system of systems level, operations reviews (usually monthly). The visualization and experiential nature of the reviews guided by data by driven by narrative and shared experience, provide motivation for changes. Gradually, sources of delay are eliminated. Some of these changes have an inevitable effect on the identities of those involved, but because they were involved and emotionally engaged, the changes are usually self-motivated rather than imposed from outside. The nmemonic we use for this is that "the lilghtbulb has to want to change itself."

With Kanban you evolve the wasteful delays out of our service delivery workflows by building an adaptive capability in your organization and a self-motivating, engaged workforce that is driven to implement its own changes. It's provess improvement that avoids resistance from the humans involved. We say "Kanban should be like water." In Eastern philosophy, water flows around the rock. When improving outcomes in creative knowledge worker industries, the rock is resistance from the people involved. To go around the rock we must implement a humane approach to improvement. We must stop trying to design out the waste and instead create the circumstances that the lightbulb wants to change itself.