In the original Just-in-Time inventory management system invented by Toyota, any factory worker could pull on an overhead line to bring the entire production line to a halt if a process or quality problem surfaced. Until the problem was fixed, production was at a complete standstill. This is now more generally known in lean management circles simply as “pulling the line”.
But how do you know when it’s time to pull the line? Toyota had their own specific process and quality indicators that determined that. But what is built into a system like Kanban that will help you to know when you have a quality or process problem in your workflow that demands a serious intervention?
Get the Foundation Right
There is immense power in those two fundamental principles of Kanban – visualizing workflow, and limiting work in progress. To those more accustomed to heavy processes with lists of rules and requirements, it may at first seem unlikely that two such simple rules could ever yield powerful change for the better in people and organizations.
But if used right, and most importantly measured effectively, these two principles can expose dysfunctions in any system. I experienced this very personally and painfully in November 2010.
Visualizing without Limits is Not Enough
I started using Personal Kanban at work to manage my own workload in roughly September 2009, having already used it for quite some time at home with the kids. Initially, I played around with a few online boards, and eventually moved to a physical board. I took the visualization part very seriously, and made sure that I made all work in progress visible in a simple To Do, Doing, Done workflow right from the start.
What I did not do immediately, was impose any Work in Progress limits. And before I knew it, I fell into the habit of using my board without limits. Although I was visualizing my flow, and that helped me to keep track of everything in my backlog, I was not achieving much better throughput than before.
Limits without Measurement is Not Enough
However, I didn’t know this explicitly yet, since I also wasn’t measuring my flow effectively. Although I had started measuring throughput over weekly cycles and had discovered an apparent two-week rhythm in the way I work, there was still a crucial missing ingredient.
I wasn’t measuring Cycle Time. And as any good Kanban practitioner or coach will tell you: If you measure nothing else, measure Cycle Time! It took a two-day course on Kanban to set me straight.
Metrics Drive Improvement
I had come to the workshop prepared with a question about why we were not seeing much improvement in one of our teams at work. As we started digging in to concepts like Cycle Time, Lead Time and Last In First Out, and the all-powerful Continuous Flow Diagram, the answer was soon staring me in the face: we were not measuring the team effectively.
And then it hit me like a ton of bricks.
I wasn’t measuring myself effectively at all.
In fact, I wasn’t really using Personal Kanban, because I wasn’t using the tools that it comes with to drive continuous improvement at all. Until that moment, all I had really been doing was getting to know and maintain the status quo of my existing workflow.
And the status quo had quietly turned into an overloaded value chain with an alarmingly long Cycle Time, an even worse Lead Time, and all the symptoms of an unhealthy system: short temper, sleepless nights, lack of empathy towards others and generally feeling hounded by my own conscience and not enjoying anything I was doing.
It was time to pull the line.
This is Part One of a series. Part Two focuses on a deeper analysis of exactly what went wrong and why. Part Three will focus on some of the changes I made subsequently.