I gave an internal workshop about Kanban a couple of days ago, and the colleagues who were there looked enlightened when I mentioned that Kanban should visualize the whole process, because this is the place where it can help the most. Don’t get me wrong, it is also fine to have Kanban on the team level, but the real optimization and improvement should happen on the highest possible level. Since their reaction surprised me - I thought the goal of Kanban was clear to them - I decided to write a bit about the reasons. A little repetition won’t hurt.
The first core principle of Kanban says: “visualize the workflow” which means that we should make the steps of our processes visible so that we have a clear picture of what happens after the customer sent us a request and we deliver a product. In case of a small company where there’s a direct contact to the customer, and delivering the product does not involve a third party, the [work]flow can be visualized quite simply:
However, large companies tend to have complicated processes, and several teams are participating in the whole flow:
Unfortunately, it is very common practice to improve these teams individually, which is good, but doesn’t help as much as one would expect. Until the flow is not visualized and managed as a whole, the teams seek to improve their way of working - or do nothing at all - locally, and to maximize their throughput. Let’s take as an example, a high performing analysis team which produces a lot of documents and ideas about what the company should deliver in the near future:
It can happen that the development teams cannot take the whole output from the analysis team, so the work items pile up between the teams. If you look at the teams locally, you can see that they are performing well, even the development teams, but visualizing the whole flow points out that there is a huge inventory between the teams, which costs a lot of money for the organization.
The lead time - the time an organization needs to deliver a customer request - demonstrates the problem even better than the throughput. Let’s say that the mentioned development teams manage to reduce their lead time from 5 days to 4 days. This is a huge accomplishment, but when we have a look at the whole organization’s lead time which was - let’s say - 21 days prior to the improvement and is 20 at the moment, we have 16 days, which just disappeared in the organization. This is the bottleneck we should eliminate.
The practices of Kanban are designed for the whole organization. They are applicable to teams as well, but an organization benefits more from eliminating high level bottlenecks than solving local issues, and this is the ultimate goal. In the example above, I would rather check where the 16 days went, and try to find a way to reduce the inventory between analysis and development.
comments powered by Disqus