The Humble Board Backlog

As I walked around the production area I could feel the change in the atmosphere. We have introduced the Toyota Kata method a few month before and at that time people were quite happy to see us. We could discuss issues from the board or issues that were not written on the board, the new process of handling them and so on. To put it in poetic way, there was hope in the air.

Slowly the situation changed but like the proverbial frog in the warming kettle, I was slow to notice it.  There were fewer issues on the boards. The board meetings became more formal and shorter. We had days when we had no issues on the boards although the production target was not met. The operators stopped welcoming us . It felt as if we were becoming just another nuisance designed by management to make their life more difficult.

So, I chose to make a few walks in the production and simply ask people what went wrong.  The answer was unanimous and very simple. 

• “Why should I write the problems on the board? People come, look at them and then nothing changes. You told us that this will be different, but it is the same old routine, except that we can now see that no one really cares”.  – was the answer at every machine I stopped at.

This was a scary message. Was this really all we achieved? Of course it is important to make errors visible,  it is one of the key points in Toyota Kata, but not having a continuous flow of solutions to match the flow of problems will only generate frustrations and will make things worse than before. In theory, we do have a cure for this – but in practice it is surprisingly difficult to implement it. I mean the often-neglected element of the Kata implementation – the backlog at each board.

This is a simple idea. Every time we visit the boards we split the reported problems in two groups : those that have an immediate solution and those that take time. As it is not practical to leave the longer-term problems on the board until they will be addressed, we   record them in  the board backlog and delete them to leave room for new problems for the next day.  The thorny question is, what will happen with these problems afterwards?

This was the part we neglected at the factory, and it was my fault in the end.  I should have insisted more that we built a standard process routine around the backlog from the start. This standard process includes regular reviews of the backlog files per each board with the local responsible and anyone involved in delivering solutions and after each review feedback ON the board so that everyone can see what is happening with the deferred items.

In my defense, this process is not easy or even advisable to standardize. Some factories might have their way of dealing with such problems and then we do not want to interfere. It is important to avoid the impression that we want to reinvent the wheel and replace processes that function well with something new, Other factories might believe that they have a working process dealing with longer term issues but in fact that process is not working except on  the principle of  “file and forget”. At the beginning it is impossible to figure out what the real process is like, so waiting a bit  to see is not a bad idea. But, as demonstrated in this case, one can wait too long.

So, having a backlog per board in itself is not enough, without a routine. We need to define early the way the backlog will be handled, and this process needs to be transparent to all. Errors in handling the backlog must be just as visible to everyone as the problems at each machine. Successes most be made just as visible and celebrated in the same way as any success at a machine. If we miss that part, the chances of destroying the whole initiative are very high.

So, how should we do it? I would use the standard PDCA thinking to answer this: let us define a target condition – which is roughly that what I described in the paragraph above. Once we agree on this vision, we can start working on the obstacles that keep us from reaching the target, These obstacles will differ from one organization to the other and this is absolutely OK. Some organizations have digital tools and want to use Teams to implement the process, others will want to use their habitual Excel files, others have a maintenance tool that can be diverted to be used for backlog management – and this is all absolutely acceptable – as long as the operators at each board have full visibility of what happens to the items that were moved to the backlog, and more importantly, that those issues will be continuously solved. The goal is that we all forget the file and forget method after that.

Not having a backlog process can be deadly for our initiative. On the other hand , implementing a living and functioning process around it will be strongest element in assuring the sustainability of Kata in the organization. To close with another plant visit, I vividly remember a Gemba walk I did in plant where I asked an operator about an issue I  saw  few weeks before this visit, on the board.

• “Oh, I am not worried about that at all” – answered the operator. “It is in the backlog, and I am confident it will be solved as soon as possible”.

These are the moments when we see that our initiative is really working. No one talks about Kata or Lean – just good everyday processes and trust in each other. And in the end, this is exactly where we want end up.