Skip to main content

The Kanban Lens: a way to see

The Kanban Lens is a way to see your work. Specifically it asks us to see:
  • work as flow 
  • workflow as knowledge discovery steps
  • knowledge work as a service
  • organizations as networks of services
I got involved with the Kanban community not very long ago - in 2012. I wanted to understand what the Kanban method was. People were saying “it’s better than this” or “worse than that”. But they weren't telling me what it was! The only detailed explanations came from critics or tool vendors, and to be frank neither of those sources were particularly reliable. I knew about the general practices of Kanban and its principles for change management. I even understood kanban systems, which are used in Kanban, just as they are in manufacturing and delivery systems, to ensure we only start work when our customers actually want it, and we have the capacity finish it.
Video of the "Kanban Lens" lightning talk (7 minutes)

But that still didn’t explain what the Kanban method was.

A few years ago Rodrigo Yoshima used an eye-opening phrase in a talk he did at Lean Kanban North America: the “Lean flow paradigm”. It helped me understand that Kanban is not a process, or a recipe, or a framework. It’s how to see work. This is what brings together the many and various parts that make up the Kanban method. In 2013, David Anderson blogged about this, coining the phrase “the Kanban Lens” and recently I’ve been talking to David again about its definition, looking for a simple form of words that captures the Kanban “way of seeing”.

There are four elements to the Kanban Lens.

1. See work as flow

Firstly… “See work as flow.” Or more explicitly: See work as a flow “from customer need, to needs met.” This is the starting point for using Kanban. Before you change the organisation, or the process, or the roles and responsibilities, or anyone’s job title, change how you view your work. Seeing work as flow may seem obvious. Except that this is completely against most managers' and most professionals' instincts. It's not how work is traditionally managed. When you look at what people actually do, it's clear; most of us are more concerned about people who are not busy, than work items that are not flowing!

Change your viewpoint. Don’t view your work as being busy at your skill, or your role. Work has value because, we fulfil customers’ needs. By visualising work and ensuring it's made up of small, distinct items, the flow of work becomes visible. Ensuring each work item is coherent and valued by the customer, means genuine value can be delivered to the customer as each item is delivered.

That’s how work flows. Workflows... that's the second element of the lens...

2. See workflow as a sequence of knowledge discovery steps

Workflow as a sequence of knowledge discovery steps is something that often puzzles people. It cuts across how we've traditionally looked at workflow - as hand-offs between individuals or teams. However the columns on a kanban board should not be viewed as representing the teams of people that handle the work. Look through a different lens. The workflow shows the progress of the work item, through different learning activities, until we know enough about each item, to convert the ideas and options into delivered value.

“Really? How can we expect a linear monotonic process to represent such complex activities?”

The answer is that we don’t, and it doesn’t. The steps in a Kanban process are states of the item. In each state there’s a dominant means of learning (of knowledge discovery), using people and skills as needed. This is how to build effective, improvable services.

3. See knowledge work as a service

The third element of the Kanban lens is to “See knowledge work as a service.”

Again this raises eyebrows. “Isn’t it obvious that knowledge work is a service? Accountants and tax men call it a service. The product is intangible. There is no manufacturing involved.” But that’s not the source of the controversy. Our instinct is to manage what’s visible – the people; rather than what’s invisible – the work being produced. The Kanban Lens asks us to focus on the work, not the workers, and to see that work as a service.

A service implies the existence of a customer, needing, and ultimately benefiting from, the work.
It implies care on the part of the service provider…
  • to know what makes the service fit for the customer’s purpose, and 
  • to what degree, and when, it can be delivered.
Sometimes a service delivers to an internal customer. That’s okay, indeed it’s inevitable in larger contexts. But don’t lose sight of the real customer, nor those that deliver direct to that customer. Our work enables them to fulfil customer needs.

4, See your organisation as a network of services

Multiple inter-dependent services require organising, and that's where the fourth element of the lens comes in. “See your organisation as a network of services.”

Network here is a general term. Typically we see
  • chains of services 
  • hierarchies of services, and
  • inter-connected services 
We can even see multiple services on a single board, as this one from Wikipedia, which has chains of services… (sequences), hierarchies of services… (decomposed work, with the lower level items handled by different services), and inter-connected services… (where blockers on work items on this board are work in someone else’s service).
Sample Kanban Board.png
[CC BY-SA 4.0 (], via Wikimedia Commons]

These networks must be balanced by adjusting the policies and resources to ensure flow and timely delivery. Management cadences for improvement are therefore vital, particularly an Operations Review, which interacts with multiple services.

Scaling Kanban depends on this first step of seeing the organisation differently… as a network of services. The "org. chart" is no help for this. But when people see the services, and their customers, they can
  • self-organise to the work
  • cut the waste of siloed thinking and redundant activities, and
  • generate improvements from within… across the organisation.
This is what “Whole Organisation Kanban” means. It’s all a part of looking at work differently, using the Kanban Lens to...
  1. See work as flow (from customer need, to needs met), 
  2. See workflow as a sequence of knowledge discovery steps
  3. See knowledge work as a service
  4. See your organisation as a network of services
That’s the Kanban Lens!

References and Credits
Anderson, David J. 2011 “Understanding the Process of Knowledge Discovery”. DJAA blog: http://www.djaa. com/understanding-process-knowledge-discovery
Anderson, David J. 2013 “The Kanban Lens”. DJAA blog:
Anderson, David J., and Andy Carmichael. 2016. Essential Kanban Condensed. Lean Kanban University Press.
Carmichael, Andy. 2013. “How to Adopt Kanban”, Improving Projects. 2013/05/how-to-adopt-kanban.html
Carmichael, Andy. 2017. "Sample Kanban Board“, CC BY-SA 4.0 via Wikimedia Commons. wiki/File%3ASample_Kanban_Board.png 
Ebbesen, Bill. “Lenses” Photo. Transferred from en.wikipedia, CC BY 3.0, w/index.php?curid=11430342
“Kanban (development)”. Wikipedia. Retrieved July 7, 2017, ment)
Kennedy, Michael. 2012. “Set-Based Decision Making”, Lean Software and Systems Conference, Boston, MA. Video:
USDA, “Large format camera” Photo.  PD-USGov-USDA-ARS. Large_format_camera_lens.jpg

Yoshima, Rodrigo. 2013. "Management and Change - Avoiding the Rocks," Lean Kanban North America,

Zheglov, Alexei. 2014. “Beyond VSM: Understanding and mapping your process of knowledge discovery”, Lean Kanban Central Europe. Slides:, Video: 114542264 


Popular posts from this blog

Does your Definition of Done allow known defects?

Is it just me or do you also find it odd that some teams have clauses like this in their definition of done (DoD)?
... the Story will contain defects of level 3 severity or less only ... Of course they don't mean you have to put minor bugs in your code - that really would be mad - but it does mean you can sign the Story off as "Done"if the bugs you discover in it are only minor (like spelling mistakes, graphical misalignment, faults with easy workarounds, etc.). I saw DoDs like this some time ago and was seriously puzzled by the madness of it. I was reminded of it again at a meet-up discussion recently - it's clearly a practice that's not uncommon.

Let's look at the consequences of this policy. 

Potentially for every User Story that is signed off as "Done" there could be several additional Defect Stories (of low priority) that will be created. It's possible that finishing a Story (with no additional user requirements) will result in an increase in…

Understanding Cost of Delay and its Use in Kanban

Cost of Delay (CoD) is a vital concept to understand in product development. It should be a guide to the ordering of work items, even if - as is often the case - estimating it quantitatively may be difficult or even impossible. Analysing Cost of Delay (even if done qualitatively) is important because it focuses on the business value of work items and how that value changes over time. An understanding of Cost of Delay is essential if you want to maximise the flow of value to your customers.

Don Reinertsen in his book Flow [1] has shown that, if you want to deliver the maximum business value with a given size team, you give the highest priority, not to the most valuable work items in your "pool of ideas," not even to the most urgent items (those whose business value decays at the fastest rate), nor to your smallest items. Rather you should prioritise those items with the highest value of urgency (or CoD) divided by the time taken to implement them. Reinertsen called this appro…

"Plan of Intent" and "Plan of Record"

Ron Lichty is well known in the Software Engineering community on the West Coast as a practitioner, as a seasoned project manager of many successful ventures and in a number of SIGs and conferences in which he is active. In spite of knowing Ron by correspondence over a long period of time it was only at JavaOne this year that we finally got together and I'm very glad we did.

Ron wrote to me after our meeting:

I told a number of people later at JavaOne, and even later that evening at the Software Engineering Management SIG, about xProcess. It really looks good. A question came up: It's a common technique in large organizations to keep a "Plan of Intent" and a "Plan of Record" - to have two project plans, one for the business partners and boss, one you actually execute to. Any support for that in xProcess?

Good question! Here's my reply...

There is support in xProcess for an arbitrary number of target levels through what we call (in the process definitions) P…