In a recent Post, Orry Fiume argued that Lean is a time-based strategy – that in fact “time is the currency of Lean.” I don’t usually spend a lot of time with social media or reading blogs, but did so over the holidays and found that Orry’s post has been widely shared and discussed on other forums. I’d say that’s an indication of how important the topic is today.
Clicking around, I saw essentially two arguments being made against the case for lean as a time-based strategy. The first counterargument was that quality should come first; the second was that lean is about problem solving, and prioritizing time is the enemy. Actually, both positions argue that time is the enemy.
If you have a deadline of any sort, a delivery commitment, you have a time constraint. A deadline may be tied to the delivery of a shipment (the truck arrives at 4PM), or linked to a customer requirement (the museum needs the sculpture by end of April); it could simply be the expected timing of a handoff to the following process. Takt time is a way of translating customer requirement into a common time bucket for each process (and serves various purposes, including “a management tool to indicate at a glance whether production is ahead or behind”). Whether you can find an easy application of the takt time concept (such as its classic application on a moving assembly line) or if applicability seems less apparent, creating and monitoring takt time recognizes that you still have a deadline. And a deadline can be translated into a rhythm for each producer in the system (and everyone is a producer, either directly or indirectly).
It is interesting indeed that in these conversations the notion of time inspires so much fear. Certainly, time can be misused: deadlines imposed without full understanding of the work to be done; mistaking cycle time for takt time (or vice versa – for more on this and various critical terms of lean operations, read the series of definitions in the Lean Lexicon under the heading of “Cycle Time-Related Terms Involving Time”); milestones used as opportunities to blow smoke about what is going well in order to buy time to skate around the real issues; time pressures that stress people so they don’t do their best work. Ad nauseum.
But, TPS uses time as an enabler. An “enemy”, perhaps, but one to make somehow into your friend, your partner. Perhaps it is easier to see the positive role of time in establishing smoother, high velocity flow compared with slower, more erratic operations. But, no matter, time can be tapped into to enable deep, consistent problem-solving.
Being right means being right in time. While Apple was right with the idea of a hand-held device you could write on and carry around with you, it was wrong in time by more than a decade – in the late 80s Apple created video mockups of a product called Knowledge Navigator which was to be a tablet the size of an opened magazine…this perfect description of the iPad became the Newton, Apple’s most catastrophic failure. Digital Equipment Corporation CEO Ken Olsen was right that a computer on each desk was inferior to centralized storage of data (what we call the cloud); he was however wrong by more than three decades. Every tech gadget released from Silicon Valley or every car from Detroit could benefit from waiting a little longer for the next gen technology – but, if it’s not released in time, no one will buy it.
Perhaps you also have had this experience. I remember so well, once (well, more than once), I insisted on extra time for an important (so we had decided) project so I could build in “extra quality”. Delivery was late. The opportunity was lost.
But, thinking in terms of “deadlines” may prompt a mental impression of linear flow when in fact there are multiple flows competing for attention; it may be more useful to think in terms of cycles rather than linear flow. Cycles of work, cycles of improvement, cycles of experiments, cycles of learning. And what is a cycle without a cadence?
Source: James Clear
Nigel Thurlow, the Toyota executive tasked by the company to meld agile with TPS, describes scrum as time-bound PDCA. I’ll buy that: a PDCA structure, a kind of kata, a routine for standardized work & kaizen. For success in any change or management initiative, We’d like to establish cycles and to make PDCA time- and structure-bound. We can use that as our key operating design principle – PDCA is both the embedded structure and the output (in the form of ongoing PDCA). The embedding is aided by ensuring it is time-bound.
How does time enable better problem solving and better quality? By adding a critical dimension to predictions. In business or any other task-based organization, predictions are most (only?) useful when they include the dimension of when. When will we learn from this experiment? When will this technology be ready? When will we identify the skills required so we can commence with the hiring process? When will we deliver the product?
Flow is the optimal psychological state for a human, according to Mihaly Csikszentmihalyi (who described it as “a state in which people are so involved in an activity that nothing else seems to matter; the experience is so enjoyable that people will continue to do it even at great cost, for the sheer sake of doing it”) and, the optimal operational state for a business. Flow means smooth movement from A to B, from input to output, from thought to thought. Flow is interrupted whenever there is imbalance in time between A and B, between input and output, between thought and thought. That interruption is turbulence and turbulence is the eternal enemy of flow. Turbulence is to flow as entropy is to enterprise vitality – they are both natural forces: what do we choose to do to combat them?
So time, or timing, is present at every consideration of work, of system development, of even organization purpose. Today’s most valuable company – Amazon – will one day be gone. Yesterday’s most valuable – GE – isn’t the most valuable anymore. One day it will be gone.
A valuable lesson in time and quality
I learned an important lesson about time and quality and how they relate to problem solving and waste in a 1992 visit to Detroit Diesel. I had a dual appointment at the time, splitting my time between the Toyota Technical Center, USA and Toyota Supplier Support Center. Toyota had a close relationship with Detroit Diesel owner Roger Penske. My visit was a friendly one and entailed the opportunity to shadow the legendary leader (and, not the focus of this discussion, but I can confirm that the many accolades Penske has been awarded are well-earned) for a full day.
Penske had taken over DD from GM just a few years before. Up until then DD had been a perennial problem for GM – poor quality, high costs, troublesome labor relations. All the usual Detroit Three symptoms. Within three years, Penske had executed an amazing turnaround. Quality improvements that had been deemed impossible. Labor relations that rivaled the best in the US. Costs, however, were still too high.
So, walk the gemba. A point of great pride of the plant operations team was the assembly stations. Engines (big engines) were guided one at a time into workstations manned by a single worker. The worker would signal when a completed – with perfect quality – product could leave his station and another would be delivered to take its place. The worker would then have a target of about (my memory) eight or so minutes to perform his assembly work, complete with quality check at the end. There was much pride in the fact that the worker could take as long as needed to assure perfect quality. Only the worker released the product to the next operation and only after ensuring required quality.
It all sounded good – other than the obvious fact that flow was totally broken as a result of all the parallel-processing individual work cells – until we watched a few operations go through a few complete cycles. It turned out that within the eight-minute standard time was far more waste than work, with most of the time spent on workarounds for abnormalities that shouldn’t exist in the first place (walking, looking, getting, checking…). There was plenty of motion. But motion doesn’t equal work.
Leaving wasted time in a job cheats everyone. The customer is cheated by having to wait for the product. The company (and owner, investor) is cheated by having to install more capacity than is needed. And the worker is cheated by having their valuable human time wasted. Imagine all day, every day, wasting four out of eight minutes – half of your effort – on tasks and motions that needn’t be there at all.
More recently I saw the same phenomenon in Japan at a Toyota plant that builds Lexus vehicles. The plant was running at a slow pace, a takt time of around two minutes, as I recall. Quality output from the plant was great – probably the best quality output of any auto plant in the world. There were few vehicles in the final repair area. And – a telling piece of intel – there was a notable paucity of andon pulls!
Fujio Cho has spoken about this: “When I hear a production line never stops and there are no mistakes or problems, I would say that is because they have not challenged themselves”. Taiichi Ohno went so far as to say, “I would hope to design a system that can fail (or lose money) when defects are produced”
That holy grail of operational stability starts with a workforce that shows up on time determined to build in quality. Paying attention to time does not mean you have to overwork, but it does mean we can establish rhythms that allow work that is steady. We want work to be steady, so we can establish flow, so that we can supply our customers what they need when they need it. Flow is operational nirvana.
Few andon pulls. And few line-stops occurring throughout the day. What to make of that? Is that evidence of good quality being built in? Is it evidence that workers are facing few problems? Is it evidence of an overall high-quality operation?
Casual observation might lead one to conclude the answer to those questions is yes.
But, closer observation (of the WORK!) revealed a different story.
There is good in the situation we observed, of course. Quality problems are evidently being uncovered at the source in real time. The worker has a sense of ownership, stemming from the fact that they do, indeed, own the quality outcome. Those are two powerful positives.
Those positives make it hard to see the underlying, insidious, and therefore critically important problem that is endemic to such an operation. To explore, we need to go back to the matter of time.
Time is a crucial element to good job design that employed properly can support the building in of quality. And that applies to ANY job, from production line worker to stylist to entrepreneur to CEO to bureaucrat. Great job designers embrace time as an ally, asking such questions as: How much time is consumed by the value-creating work and supporting processes today? How much time should they require? Should we add more time here, take out time there? All those questions are answerable, but they are only answerable by studying the work itself. Work takes time.
Time is a limited, and perhaps our most precious, resource. As we take time to complete our work, a customer is out there waiting. Or not.
Back to Orry Fiume’s post, yes, lean (TPS) entails a time-based strategy. When we don’t value time, everyone is cheated:
- The customer is cheated
- The company is cheated
- The worker is cheated
Certainly, we don’t want to cram in more work than can be done effectively within a given time bucket. But the question that must be addressed to ensure we make precisely that mistake is to know how much time is truly required to complete the task. Sounds easy. But, take a look around your place of work. Does everyone have enough time to do their work? Is their work full of waste and rework (poor quality)? How much time does the value creation actually require? It’s usually not so easy to know the answers to those simple questions. And you certainly WON’T find the answers if you don’t concern yourself with questions of time.