Gemba Panta Rei

We recently had the opportunity to host 15 top executives from a multi-billion dollar manufacturing company for 3 days of Lean training, benchmarking tours, and strategizing. During this process we gained insight into Takt Time.

These executives were all knowledgeable in Lean, many of them having sponsored dozens of kaizens or Six Sigma projects. They were familiar with the basic Lean lingo, including Takt Time.

When it came time to go through the Factory Flow Simulation, they split up into two teams. They competed in designing a production system to minimize inventory and lead-time while maximizing profit building airplanes. When it came time to introduce Takt Time and line balancing to the exercise, we were in for a surprised. None of these highly educated and experienced executives made the connection between the time it took to build a plane and the Takt Time, and the effect on staffing.

As we explained how Takt Time could be used the VP of Marketing got it right away. He was arguably the person with the least amount of experience and knowledge of Lean, traditional manufacturing or work balancing.

The lesson learned was that Takt Time is counter-intuitive. It is deceptively similar to concepts of line speed and total cycle time (though totally different). It is such a simple concept that people assume that the 'get it' without working through it backwards and forwards. Because of this, we advise executives to assume they do not understand Takt Time and approach it with an open mind.

One of the best ways to drive home the concept of Takt Time for executives is to ask them to figure out Takt for each of their major Value Streams. This will force them to figure out available time and demand for each one, which in itself can be an eye-opening exercise. This will give them a sense of the heartbeat of their business, in addition to raising interesting questions about how demand is determined and work hours are set.

Posted by Jon Miller at 10:13 AM | Permalink | Comments (3)

Extreme Programming is an approach to software programming that puts two or more people in a team to work on one piece of code, at the same time, on the same computer. It might seem counterproductive to have two sets of hands and brains working on one computer, but in fact the results are that better code is written quicker with fewer errors. There are strong similarities to Lean in this method. The key elements are Flow, Pull, and Quality at the Source.

The work flows, since while one person is typing in the code, the next person can be thinking ahead, in effect performing the next operation. This creates a pull, with one coders saying "hey, let's try this next" to keep the process moving. This speeds up not only the overall cycle of producing code, but evens out the workload by allowing both minds to be spinning idly (trying to figure out what to type) for shorter periods of time.

It is also easier to flow one piece of code at a time, since the two coders are not separated by time and space. Each piece of code can be reviewed right away and checked for errors.

Although when producing a physical product or working on an engineering project you are rarely working on the same components (you can't have two sets of hands assembling the same parts very easily) this is actually possible when building code. That is because it is mostly so-called creative work, more akin to design than putting standardized widgets together (not at all a bad thing in itself).

This is a very intriguing area of study, as it may point the way to Extreme Engineering, or Extreme Accounting, or Extreme Doctoring. Stay tuned for more from the frontiers of the Lean Office.

Posted by Jon Miller at 10:59 AM | Permalink | Comments (0)