Last year in the Lean Kanban University conference series I was talking about flow efficiency and how we measured and used it with one of my old teams. My friend Chris McDermott asked me to write a post about it, so here it comes. Like other metrics such as cycle time, takt time, and throughput, flow efficiency comes from car manufacturing. It shows the time in working time/lead time in progress percentage for a given work item (check out the equation on the right). So a 100% flow efficiency means that the work item is never idle during processing. If a work item was done in 60 minutes and its flow efficiency was 5% means that one worked only 3 minutes on that particular item. In a factory it must be fairly easy to calculate flow efficiency because the flow is semi- or completely automatic, and therefore the machines that move the work items around can log the pickup and delivery times and that makes it easy to calculate the working time itself. In software development such logging would increase the time spent on administrative tasks, and the current electronic Kanban tools don’t know when a work item is idle or is one is working on it. It is not a lost cause, because we know the overall time we spent on a work item, and we also know the lead time.
With the team I mentioned before, we used a physical Kanban board and redmine for issue (later work) tracking. At the end of each day we added the spent time to each work item we had been working on. When a work item was done, we’d get the data out of redmine, get the lead time from the post-it note which after a simple division gives us the flow efficiency of that item. Of course, you don’t have to use redmine, there are other options as well. You can write spent time on the post-it, or add it into the description of a work item in case you are using an electronic Kanban board. The goal is to know the time you’ve actually spent on a work item (I’m assuming that you know your lead time).
There was a time when we had a very low flow efficiency: it was around 5% and that was kind of scary and unacceptable. So we did a retrospective where it turned out that our work items were waiting unnecessarily for days in a particular column. After a long discussion, we changed our process and introduced a daily deployment to staging (pre-production) reducing the days to maximum one day and that helped us reduce the lead time from 9 days to 5 days. Flow efficiency actually helped us find a flaw in our process.
Flow efficiency is a tricky measure. First, you cannot determine the desired percentage in advance because it has a certain lag: you’ll only know the lead time and working time when you are done with the item. Second, software development is not car manufacturing. We don’t do the same work in the same environment all the time. We have very high uncertainty, options, changes, multitasking and humans in the process. I don’t want to talk about all these things except multitasking. We see it as a wrong thing, but if you think about it it’s that something we have that car manufacturers don’t. In their case if the flow efficiency is low it means that the factory doesn’t actually do anything. On the other hand, in our world it means that we are working on other things as well. We can actually wait and work on something else, maybe something more important. That is not possible in car manufacturing. Among other things that’s why David J. Anderson told us at various conferences that having a flow efficiency above 15% is normal, and above 40% is good.
And third, the context really matters. We had 5% which is below normal according to David, but it was fine for us. As far as I remember we were close to the end of that project and what we really needed (as it turned out later) is a lead time that is shorter than a working week (for planning purposes), and we achieved it. Our managers were happy with our results and we had other things to sort out, so we actually never checked flow efficiency again. We learned how to work with lead time instead. But this wouldn’t have happened without checking out the flow efficiency.
I hope that this post will help you to fine tune your Kanban system and get the flow efficiency from it. Don’t forget the points I mentioned earlier: collect your spent time, do not aim for a specific flow efficiency number, know the difference between car manufacturing and software development, and know your context. A couple of months ago David wrote a nice post about flow efficiency that can provide you more details. Happy tuning ;-)
comments powered by Disqus