The idea of takt time comes from car manufacturing. It shows the elapsed time between two completely assembled cars leaving the factory floor. If the takt time is 2 hours, it means that the factory produces 12 cars a day (24h/2h = 12). With the use of takt time people in car manufacturing can detect problems in production earlier. Let’s imagine that the factory has to deliver 150 cars in 2 weeks. The measured throughput is 84 cars a week (and the takt time is 2 hours), so the factory can deliver because based on the throughput it will deliver 168 cars until the end of the second week. Changes in the takt time can tell the engineers if they will be able to deliver or not. For example, if the takt time increases to 3 hours at the beginning of the second week, they can assume that they won’t be able to deliver: they have already produced 84 cars in the first week, but with a takt time of 3 hours they’ll produce only 56 cars during the second week and that is 140 cars in two weeks. So they have to do something. It is a good and useful measure in car manufacturing, but software development is not car manufacturing.
Car manufacturers are producing the same kind of car over and over again, whereas software houses rarely do exactly the same software twice. Even on the smallest possible level there are only similar tasks, but not the same tasks. Moreover, in software development we don’t have to deliver 10 features in a week (unless the organisational bonus system is based on the number of delivered features), we have to deliver the one feature the customer needs/asked for. Therefore the takt time in its original form - throughput prediction - is useless in software development. However, this doesn’t mean that we cannot have it, but we need to adapt it. If the takt time - frequency of finishing tasks - drops or increases that is an indicator of mura (inconsistency, unevenness or unbalanced demand situations in the system) or poor planning. If the takt time is inconsistent or has pikes in your Kanban system that is an indication that something is going on that requires your attention.
When I’m talking about Kanban and Lean in workshops and talks, I always emphasise that we shouldn’t take practices from car manufacturing and apply them unchanged to software development. Using takt time in its original form would drive us towards increasing the number of completed features and that is very dangerous. I’m pretty sure that any organisation can increase the number of delivered features (throughput), but delivering the right features is a completely different story. However, finding process issues earlier is a good thing, and takt time is one of the things that can help do that.
comments powered by Disqus