Reading, is always the best way to connect things and ideas and see the light. Please, do try reading at home.

The light I saw today, while reading, was on the Kanban method practices and, specifically, the Visualize and the Make Policies Explicit ones. Having the Kanban 3D pillar (the "totem", as I call it on my desk, helps keeping in mind (and continually visualize!) all the Kanban method basics: principles, practices, values. Just a brief reminder as suggested by the totem of the six Kanban Practices: Visualize, Limit WIP, Manage Flow, Make Policies Explicit, Feedback loops, Improve & evolve.

I was saying something about reading. I was reading about the ideas and behaviours of 大野耐一 (Ōno Taiichi) when he was creating the Toyota Production System, and I found these discussions a very useful tool and help thinking about process improvement regardless the context in which to operate. He said that "where there is no standard, there can be no kaizen", where the word kaizen (改善) stands for 'improvement'.

What is the point here, with the Kanban method? Well, except for the fact that the method itself states "Improve & evolve" as one of its practices, the Kanban method came from Taiichi's teachings and ideas, when applied to service providers. So, even in the modern Kanban method, we must have kaizen. (Hey, even Scrum speaks about improvement: http://scrumguides.org/scrum-guide.html#events-retro!)

In this context, the Kanban method "Visualize" and "Make Policies Explicit" practices have always been considered by Kanban practioners (me, at least) as a way to say "describe the flow of value" (Visualize) and "represent the guidelines and rules to let an activity transit inside such flow" (Make Policies Explicit). Possibly true, but there is more than meets the eyes. I'd like to also add, to these practices, a further detail.

In order to improve something, you have to make it clear what are you improving and the idea of Taiichi to have a standard for the work should be integrated in your Kanban system. What does it mean? It means that you have to visualize and make explicit, not only your flow and your policies to manage it, but also your ways of working.

So, for example,

• If your Kanban system describes a software development team, you should describe you coding policies/conventions, the rules to document your code, the commit message convention, etc.

• If your Kanban system describes a law office, you should describe how to use the reference manuals, how to refer to laws inside document, which is the proper order in how to manage a client case, etc.

and so on. In any case, it's proper (and possibly mandatory) to document all processes, steps, tools, configurations, and references, as they're actually used (not the officially documented ones, the real ones, those used by working people!) so that all people are aware of the standards, all people have a clear guideline on those elements.

By having a standard that all people involved in your Kanban system can (and must) follow, you already have defined a common starting point and a common reference that can be used for improvements and can also be used as comparison point with the results of the improvement experiments.

Once the improvement experiments are then set and approved, they obviously become the new standard and they have to be visualized and made explicit in order to publish them for all the people involved in the Kanban system.

So, remember that these two Kanban practices, Visualize and Make Policies Explicit, are not only for your value flow or for step rules, but you also have to visualize and make explicit the ordinary ways of working, the procedures, the steps and the tools.

Create your standard work, and do 改善 from there.