The Kanban Lens
Regular readers who follow everything I post may already have spotted that I introduced a new way of thinking about Kanban. Like almost all of these “new” things, it isn’t new at all. In fact, the concept existed in my first book, Agile Management, published over a decade ago. It took Andy Carmichael attending my coaching masterclass in Hamburg earlier this year to remind me of it.
The Kanban Method is unpinned by the concept of “flow.” Once again, something hiding in plain sight that I hadn’t been thinking about or articulating clearly for a while. So with my Paris and Utrecht, Lean Kanban Conference keynotes, I re-introduced “flow” to the Kanban party. I used the term “Core Enabling Concepts” but we are likely to use the nickname “Kanban Lens” because they give us a way to see things – a way to see how an organization is currently structured and functioning and to then “kanbanize” that existing structure without reorganizing it. Sometimes, a different way to see is all it takes to reveal obviously conflicting policies and catalyze improvements.
The Kanban Lens
- Service-orientation
- Service delivery involves workflow
- Work flows through a series of knowledge discovery activities
Looking at a current organization through a service-oriented lens and seeing services where currently people only see functions and specializations is liberating and empowering. Service-orientation implies service delivery and therefore there must be customers for those services. It is this lens that enables the outside-in systems thinking approach to implementing Kanban that we cover in the Foundation level class curriculum from Lean Kanban University.
That work flows through a series of knowledge discovery activities is a concept borrowed from Lean Product Development. I first saw Don Reinertsen describe it in the early 1990s but he in turn credits the idea to Marvin Patterson. Michael Kennedy has also documented the same idea and I’ve tried to standardize on using Kennedy’s language.
I think many Lean consultants and many in the software development and IT space with an understanding of Lean (from manufacturing) miss the subtlety of this third concept – “work flows through a series of information discovery activities.” It does not say, “workflows through a series of people with specialist skills.” When mapping value streams, Lean people tell you to “follow the work.” I think this is a red herring for knowledge work. Trying to map a complicated value creation network and then visualize it is a distraction. It gives you an overly complicated system and the many loops and joins in the network make visualization of it challenging.
Following the work, through a series of people, also institutionalizes the handoffs between the people and masks important information about the activities performed by any one person in the chain. Since Agile Management over a decade ago, I’ve cautioned against this. We aren’t interested in the passing of work between the people, we are interested in the dominant activity to discover new knowledge about what we are creating at any given time in the workflow. This chain of activities tends to be much simpler and leads to significantly simpler and easier to comprehend visualization. The concept of a “dominant activity” implies that several activities can be happening in parallel but one is the dominant way for discovering new knowledge. For example, an item said to be “in test” has a dominant activity of “testing” but other activities such as analyzing, designing, coding may all be present at the same time. However, it is the testing that provides new knowledge. Mapping the workflow of knowledge discovery activities produces much simpler system designs than trying to map the value creation network by following the work from person to person. Yes, the tickets on the board have to circulate if the process is iterative – so what? That is just a reflection of reality – design the kanban system accordingly.
Viewing organizations through a Kanban Lens opens up new possibilities and enables us to set up extensive networks of interdependent kanban systems. Kanban scales in the enterprise by scaling out in a service-oriented fashion and it self-levels to optimize service delivery across a complex set of services, customers and their demands, through the use of a system of systems feedback loop. We call this system of the systems feedback loop, the Operations Review.
By adding the Kanban Lens to the literature and the teaching curriculum, we are helping people understand how to establish deep and extensive Kanban implementations that deliver significantly improved service delivery at an enterprise scale. The Kanban Lens isn’t new, it’s just something that was hiding in plain sight and I was taking it for granted. By making it explicit I believe Kanban will be easier to teach and easier to adopt.
[Oct 25 Note: some minor updates and corrections thanks to Karl Scotland’s probing via discussion on Kanbandev Yahoo! group.]
