Just-in-Time is probably the most misunderstood lean concept.
Objections range from “this is not for me, it only works on large industrial numbers”, to “I already have a make-to-order process, why bother”. But in a world where uncertainty prevails, a pull system helps clarify what is expected from each of us and face the topmost problems we have to address. We believe in Just-in-Time and explain why in the following pieces. Please click on the author names below to go to their essay.
I was sitting in Johannesburg (2008) at our favourite sushi spot. At the time, I felt intimidated by the inner workings of a pull system, and thought this restaurant was a helpful example to digest the sum of its parts.
Pull flow (or Kanban) in digital product development is vastly misunderstood. It is mainly perceived as a tool for process improvement, when it should be seen as a tool for developing people and talents, as originally intended.
One of our most frequent misconceptions on lean is that we can skip pull flows (too technical, too “manufacturing”) and content ourselves with the rest of TPS. We can for example work on value streams and chase wastes, or on quality and write standards. But that won’t do.
Back in my CFO days and early in our company’s lean journey, learning and deploying pull processes was the means by which we dramatically (1) improved lead time and (2) reduced inventory in our factory. Pull is a widely proven lean concept and was our proverbial light bulb turning on—”Eureka!”—in terms of making sense of how we might best reduce waste and achieve continuous improvements in our production processes and the resulting products.
Working in pull flows means creating the value the customers expect, as and when they need it. In production, it is a question of respecting the “sell one, make one” principle. In development, it is rather a matter of understanding what clients value and creating the knowledge that is lacking to deliver that value as a priority.
Pull-flow production can be difficult, but not where you would expect it to be. To find out, you have to try! It’s the experimentation I’ve done on my own ground that has allowed me to understand it.
****************
Rose Heathcote
In 2008 I was sitting in Johannesburg at our favourite sushi spot. At the time, I felt intimidated by the inner workings of a pull system, and thought this restaurant was a helpful example to digest the sum of its parts.
- Sitting down at the conveyor, you pick what you fancy eating.
- An empty, labelled placeholder remains, indicating what you consumed.
- When enough placeholders are empty, it triggers the chef to replenish in small batches.
Mesmerized by the chef’s skills and discipline for standard, I reflected on what makes or breaks such a system:
Before the crowds arrive, there is an array of sushi, freshly manufactured and ready to eat. They have a handle on demand patterns, levelling the mix and inventory. To replenish and pace to demand (make it as I eat it), the chefs have quick, responsive times and minimal mishaps throwing them off. These are the things they do well:
- Right first time – rework and defects are under control.
- 5S – needed items sit at their fingertips in a clean workspace.
- Maintained, available tools – knives sharpened, mats clean.
- Best method and standard times are followed no matter the shift.
- Raw materials and ‘sub-assemblies’ – what you need where it is required, e.g. cooked rice and sliced veggies.
- One-piece flow on speciality items, e.g. eel sushi.
- A signal (Kanban) authorizing the production of small batch sizes, e.g. 8X California Rolls.
- Flexible capacity to cope with variation in work released to the system.
I realized the importance of doing the groundwork that creates stable conditions to support the flow concept.
Not long after our delicious lunch, I observed what I call a ‘back-to-front’ pull system. I visited a South African clothing manufacturer pioneering a pull system. They dedicated time and money to it, but the CEO became frustrated and could not see the benefits. A closer look revealed a sophisticated (IT-driven) pacing system mismatched to genuine customer requirement. The customer didn’t notice any difference in performance and still placed large batch orders. Tough pill to swallow! They later worked closely with the customer to achieve ‘rapid response flow’, but that was several years later and required a complete rework of the system. Lesson learned! They had the right idea, but the pull flow could not reach potential without collaboration, customer behaviour and systemic changes, and adjustments supplier side.
Admittedly, I’ve not seen many well-oiled pull flows in Africa. Some sectors stand out more than others – fast food and automotive among them. Others only go as far as serial waste hunts and don’t connect production to downstream consumption. Or there are pockets of non-strategic batching dotted along the value stream fighting the flow design. It should be a natural progression from understanding value, visualizing value streams, to taking out waste, to create a levelled flow so that when the customer pulls you respond with the right product. While perpetually improving with each setback.
Don’t be nervous about pursuing pull flow and making mistakes while you learn – it’s hard, not impossible. First, work alongside your customers and understand what they’re prepared to pay for. It may be that they are not yet ready for what you can offer, and you can help them see the potential. Second, prepare a stable foundation for pull flow to flourish. Third, engineer quick-response problem-solving to address the many mushrooms popping up as you progress from push to pull. In this way, the organization evolves from the limits of self-improvement to cross-border customer-serving transformation, placing it streaks ahead of the competition.
****************
Sandrine Olivencia 
Pull flow (or Kanban) in digital product development is vastly misunderstood. It is mainly perceived as a tool for process improvement, when it should be seen as a tool for developing people and talents, as originally intended.
When we use Kanban as a tool for improving processes, we expect it to work the same way in all situations, with anyone, and with the same results: we visualize the flow of work, we spot bottlenecks, we remove them one by one and then we deliver faster. Simple, right? Well, chances are, we’ll be able to pick some low hanging fruit at first, but not much will change in the organization, as people are left out of the equation.
In fact, it makes more sense to set up a Kanban system once we have accepted that our organization has a major problem to face and that we need to dig further to understand what is really going on in the field. For example, we may be losing sales due to poor product quality or be low on cash because of late deliveries. In this case, Kanban is not the solution to our problem, it is the method we use to better understand the problem and the conditions that create it. Kanban shows us where we are going wrong in how we see and do the work. It helps us drill down to the smallest details, so we can spot individuals’ misunderstandings or misconceptions to use Taiichi Ohno’s term. Why is this important? Because after a while, we get comfortable with the reality as we know it, and we are no longer able to see the elephant in the room. As a result, we tend to come up with very generic solutions to generic problems, which make the situation worse. For instance, we might decide to deploy a new CRM in hopes that it will help us convert more marketing leads (I’ve seen it many times). Or we might introduce a new workflow hoping it will help improve lead time.
For example, a software development team had been struggling with bugs for a couple of years. They started counting defects and using pareto analysis to find recurring bugs. They implemented several action plans to reduce the most frequent types of bugs. Then they implemented some generic solutions, like creating more tests or adding new code review and validation steps in their workflow. These measures did get some initial results (bugs went down) but nothing earth shattering in the long run, and eventually, bugs started building up again. After these setbacks, the team decided to set up a Kanban system, starting with: limiting work to one task per person at a time, visualizing lead time and stagnations, and discussing quality with each work unit. This is helping the team drill down to specific causes of non-quality linked to how developers code, and not just process-related issues such as incomplete specifications (“user stories” in their agile jargon) or waiting for validation from experts. This is when the value of Kanban actually kicks in because discussions start revolving more around the technical gestures and the reasoning of engineers, which provides the team with many opportunities for kaizen and people development.
Over time, a more mature lean development team will continue to reduce the size of its work units so they can learn to catch very specific technical problems, much sooner. As they do so, engineers not only sharpen their technical skills but they also develop broad expertise in their domain. For example, they will more clearly identify areas in the code that are cumbersome to manipulate or specific knowledge and training gaps of the developers. Both types of problems contribute to creating technical debt over time. You can see an example of this method used by a team at Theodo, a software development consulting firm, in this Planet Lean article. In a traditional team, a programmer keeps reworking the code until it is satisfactory, so it is hard to see when they are being truly creative and when they are struggling. All you know is that, at the end of the day or the “sprint”, the task is not quite done or that it took longer to finish, but you only get a vague explanation of why it happened. This makes it impossible to come up with a solution that will contribute to the programmer’s growth. Kanban can help a development team tell the difference between the two modes (doing creative work and struggling), which is key to improving the quality of the code and developing first-class engineers.
Kanban challenges us in ways that can make us uncomfortable, at first, because it forces us to question what we do and how we do it so we can find better alternatives. It takes practice and managers who are willing to provide support and encouragement throughout the day. The whole purpose of Kanban is to trigger numerous discussions between people about quality and the conditions that create the problems. Without those discussions and an intention to learn, Kanban is just bureaucracy. The lean mantra “we develop people before we developing products” rests on the idea that any group of highly skilled and smart workers can build top notch products, and so the focus is on developing people.
****************
Anne Lise Seltzer 
Pull-flow production can be difficult, but not where you would expect it to be. To find out, you have to try! It’s the experimentation I’ve done on my own ground that has allowed me to understand it.
Several years ago, like many people who work outside the industrial sector, I started by burying my head in the sand about pull flows.
Why did I do that? Probably because I didn’t understand enough about it in the service sector in which I worked and it seemed difficult to implement because the work organisation was not at all the same as in a factory. But as my sensei told me at the time, “To understand the importance of a lean approach and the benefits of pull flow, you have to make pull flow”. And so that’s what I tried to do.
I started by looking around me at everything that could be the subject of a pull flow on my own ground to find the first experiments to do. I found 2 of them, of a very different nature: the animation of the web page of an associative site (an online service) and the management of my family’s linen (a material service). In both cases, we had customers, suppliers, raw materials, expected delivery frequencies, product families, machines, variability in orders or supplier deliveries, teams with different roles and skills.
I started… and I quickly understood both the interest but also the difficulty of setting up these pull flows, but maybe not where I thought.
First on the difficulty. It is not the technical aspect of the pull flow that is difficult in itself. In fact, the difficulty was to find myself facing my own organization (or my own disorganization), facing my individual choices in terms of activity prioritization, facing the difficulty of defining and keeping a takt time, the difficulty of clearly defining the quality of the expected service, delegating tasks, seeing the non-training of the teams on certain subjects and my own random practice of certain operations. In short, so many problems to solve if I wanted to improve the overall performance on these 2 processes. This exercise therefore first asked me to accept to see this set of things and if I wanted to improve performance, to start dealing with them, one by one.
What was the interest of these experiments: the pull flow allowed me to understand in depth the 2 services that I used to perform in push flow. Whether it was the web page animation or the linen management, I already knew how to perform them in a satisfactory way, but without having really thought about certain dimensions of what I was doing and how to improve them.
By experimenting the manufacturing of these 2 services in pull flow, I really could :
– Apprehend the knowledge/skills I needed to produce each of the two services with the expected quality, understand the ones I had and the ones I needed to develop;
– Identify all the stages of their respective manufacturing and dimension the time needed for each of them to then be able to elaborate a real “production plan”;
– Think about how to smooth this production by working in small batches rather than large batches so as not to find myself drowning (especially under the clothes…);
– To spot the triggers/signals that would alert me in case of problems so that I could react in time and protect my customers;
– Giving me the means to organize a kind of routine (with its takt time) to hold my deliveries.
This allowed me to identify the “right” operational levers to improve my “production” of services, without starting from what could have been misconceptions, based solely on my certainties.
The interest of pull flow really lies there: understanding in depth what we produce, giving ourselves the means to see the problems that prevent us from delivering a product/service with the expected quality at the right date (facing) and thus being able to solve them one by one thanks to the identified action levers. It is a way of producing that ultimately leads us to be totally involved in the manufacturing process, getting out of our errors of judgement.
Everything I have done at my level is absolutely compatible with the world of services and support functions and would undoubtedly open up new perspectives for the teams, giving them more powerful levers of action to improve their production, whatever its nature, and develop their activity.
But the commitment of such a process depends strongly on the willingness and ability of the teams and their management to accept to face their current situation, to look in depth at where today the real problems are that are blocking the improvement of their activity. A commitment that requires, it is true, a safe environment for all, based on respect for people and a management that intervenes in support of the teams. The opposite of today’s push-flow management, which focuses on what goes into the process and much less on what comes out of it.
This may be one of the major obstacles to the development of pull flows in companies, which is a great pity because it is to the detriment of teams, customers and the company.
****************
Cécile Roche 
Working in pull flows means creating the value the customers expect, as and when they need it. In production, it is a question of respecting the “sell one, make one” principle. In development, it is rather a matter of understanding what clients value and creating the knowledge that is lacking to deliver that value as a priority.
In both cases, clients will be satisfied, because they will have what they need when they need it. At the same time, the company optimises the necessary resources (the right resource in the right place). In addition, the concept of value goes beyond customers, and concerns the Society as a whole – taking into account the economy of resources is today a societal obligation.
These are already arguments in favour of working in a flow pulled by the value.
However, more importantly, the pull flow is actually a system that works mainly with people.
Pull flow is a system that allows problems to be revealed and, in doing so, a powerful tool for developing team autonomy. Through the Kanbans, the system shows at any time what needs to be done, and highlights at any time if everyone is OK or NOK. Problems (NOK) are revealed in the order in which they should be dealt with. The role of managers is no longer to manage priorities (Kanbans take care of this) but to help teams understand and solve their problems. To put it differently, the management “chain of control” becomes a “help chain”, and teams stop being under pressure to start working in flow.
What is team autonomy? It is their ability to produce (make) a product (everything that will be delivered to a customer) in a number of different cases. What does it mean to increase the autonomy of a team? It’s about increasing the number of cases where they are able to do a good job. The pull system allows everyone to know what a “good job” is (each Kanban represents a specific request). Each problem solved further increases the number of use cases where the team is autonomous. In this way, we develop the organisation’s agility, i.e. its ability to deal with unexpected events.
Too often, organisations believe they can develop problem solving without implementing pull flow. It is like letting each individual decide and understand what a “good job” is, and dealing with the issues they find most important, or more irritating, or more interesting for managers… The collective energy is then exhausted by the constant changes in priorities, the time spent solving problems that are not in phase with the challenges, and the justifications of each.
Given this, the pull flow is not only a production system, or a development system, it is above all a system for developing problem solvers. This is why it is so important not to forget it! The sustainability of our progress depends only on people.
****************
Jean Cunningham 
Back in my CFO days and early in our company’s lean journey, learning and deploying pull processes was the means by which we dramatically (1) improved lead time and (2) reduced inventory in our factory. Pull is a widely proven lean concept and was our proverbial light bulb turning on—”Eureka!”—in terms of making sense of how we might best reduce waste and achieve continuous improvements in our production processes and the resulting products.
But, as it turns out, pull was not just for the factory as I discovered while deploying lean in the departments I managed and later as a consultant in a wide variety of industries. For instance, I was working with a hospital facilitating several kaizen improvement events. One process to address involved employees who were returning from short-term disability and needed a temporary job accommodation while they got back up to speed physically. There was often a wasteful 2-5 day wait time to find an appropriate temporary role for them. So, we designed a pull system using kanban cards during one of the kaizen events.
Here is how it worked. When there were no known available jobs for a common accommodation such as less lifting or less use of the hands, the kanban card system provided a signal to a supervisor to prioritize finding a job in the company that would address the accommodation. Thus, there was always a job available quickly for common accommodations. Thereafter, the hospital was able to get people back to work the same day they got released for duty. This largely eliminated the totally wasteful wait time, reduced the frustration people felt while waiting, and improved health as well!
Another example of pull outside the factory was in a sales department’s preparation of orders for custom engineering designers. They decided to create batches of five orders. As soon as engineering finished the prior five orders, they would pull the next five that sales wanted designed. This allowed sales to constantly adjust the priority of the orders to meet customer need while completely eliminating the frantic expediting process for a suddenly high priority order that had always been slowed because of the huge amount of waiting work downstream.
A third example from the accounting department was when we decided to pull a batch of accounts payable invoices to the desk of the processor as they completed a previous batch. Prior, we pushed each invoice to one of the processors when it arrived. The batch pull system enabled simpler distribution of work with less movement and automatic load levelling per processor. It also made the amount of work to be done visible which allowed for redistribution of work activity when a significant increase in invoices occurred. Finally, the improved process eliminated the need to sort invoices for early pay discounts or other reasons since the work backlog was reduced.
I’ve seen over and over how pull is a very powerful lean tool. If so, why is it not used more outside of manufacturing? I believe there are four main reasons. Three are based on bad assumptions.
- Bad Assumption #1: Pull cannot be used outside of manufacturing
- Bad Assumption #2: Pull cannot be used with custom work (i.e. each unit varies)
- Bad Assumption #3: If the work is piled up at a workstation because it was “pushed” forward, that people will work harder so they will not feel behind.
The fourth main reason is that many people have not been exposed to the pull concept and are ignorant of its benefits. This is especially true outside of manufacturing—as with the rest of lean principles and tools.
There are effective ways to address all of these reasons. For bad assumptions #1 and #2, there are many existing examples to pull from (pun intended) in order to see the powerful impact of pull beyond standard manufacturing. For bad assumption #3, by going to gemba and asking workers some pointed questions, one will learn that “push” is actually a form of disrespect to the skills and intent of most workers. In turn, it can cause many long-term problems (e.g. turnover, resistance, poor attitude, performance, etc.). For the fourth reason, hopefully these articles, lean learning events, and other lean literature will spur people to learn more about the great advantages of pull.
********************************
Catherine Chabiron 
One of our most frequent misconceptions on lean is that we can skip pull flows (too technical, too “manufacturing”) and content ourselves with the rest of TPS. We can for example work on value streams and chase wastes, or on quality and write standards. But that won’t do.
Pull flows are an indispensable prerequisite to facing real problems. And I can give you at least 6 reasons for that.
First, pull flows are in fact levelled pull flows and they first rely on understanding the takt time of a product. How often should we manufacture that product? Or deliver that service? Checking whether we deliver at customer takt time or not, at any time of the day, is a way to ensure we do not overly focus on our internal problems (ensuring we make the most out of this terribly expensive equipment, getting bored in endless meetings…) but rather make sure, at any time of the day, that we deliver what we promised. Learning at 10:00 am that you are already late on your final product assembly is better than discovering it at the end of the day. I have observed how Toyota’s supply chain relies on the 15 trucks they send per day to their suppliers, to set the pace and provide clear signals of whether they are on takt or not.
Levelled pull flow is a major change from make-to-order. Promising as I often see that any order will be delivered within x hours or minutes, whatever the volume of orders, means that we will have to adjust our production capacity from one day to another (be it delivering mails, making hamburgers, manufacturing goods or answering a request on legal advice). In other words, make-to-order is importing the variability of the customer demand into our production. Well, I have seen countless examples of operators or mailmen or engineers suffering from this mura. Discovering at the last minute that you can’t go and collect your kids at school because of an excess number of orders can be painful if it happens again and again. And inevitably, poor quality will develop when working fast or long hours, and accidents will happen. With levelled pulled flows, on the other hand, the effort is constant, and peaks are well anticipated, leaving time to deal with problems as they come.
And this has an interesting consequence: all of a sudden, the ability to predict reliable forecasts on customer orders, so as to calculate a takt time for next week, becomes a key skill. It requires understanding factors underlying demand, a fine analysis of customer usage, more collaboration with intermediates in distribution and interacting far more often with your customers. This can only help you do a better job on your market. All the companies I have seen work with pulled flows confirm they have considerably improved their collaboration with their customers and, ultimately, with their suppliers.
This is not all: the delivering team’s life changes. You need to deliver at speed with high quality to keep up with the takt time, and this means ensuring that everyone in the team knows the difference between what is ok and not ok, so as to be able to pull the andon. Defining the boundary conditions for quality is a challenge in itself: what is a good insurance proposal, pizza, university lecture, whatever the team produces? When do you say it is still ok, and then no longer ok? And do we all agree on it?
You also need to produce a bit of everything every day, to keep up with the customer demand, and that requires excelling at changeovers (and this is true for manufacturing but also when navigating across ERP screens to move to a new legal entity or a new functionality : if the navigation is complex, you will tend to batch).
Lastly, failing to keep up with the takt time will reveal every single hiccup in the flow and all this requires complete new skills from the team leader, who will need to develop collaboration, kaizen and learn to see the gemba with the operator’s eyes. This will also reveal where money has been up to now mis-allocated (sophisticated machines or systems uneasy to master, unavailable maintenance skills, operations solely focused on delivering, leaving quality to others).
Pulled flows are not just a manufacturing fad. It is the only way we know to dig deeper into our jobs, collaborate better, and eventually face all the real problems.
—
AUTHOR BIO: LEAN SENSEI WOMEN
Coming from different continents, horizons and professions, the individuals who form Lean Sensei Women are all recognized lean Senseis, who help companies and organizations build sustainable growth through lean management. They believe in the development of people, respectful of both teams and environment, with a view to produce more value for customers and to society.
Catherine Chabiron: Board Member, Institut Lean France. Author of Notes from the Gemba in Planet Lean and executive lean coach.
Jean Cunningham: Jean Cunningham, a former CFO and LEI board member, is widely recognized for her pioneering work in lean business management systems and the lean office. Her books include Real Numbers, The Value Add Accountant, and Easier, Simpler, Faster. She is Chairman of the Lean Enterprise Institute.
Rose Heathcote: Author of Clear Direction and Making a Difference. Rose is personally dedicated to transformation in Africa, bringing change to organisations for the benefit of employees, customers, shareholders and the environment.
Lucy Liu: Currently the Head of Supply Chain Academy for Asahi Beverages, Australia and New Zealand. Over a 28-year stint with Toyota starting at the shop floor, she progressed to management roles include Australia TPS Office and Capability Development Department Manager.
Sandrine Olivencia: Lean sensei and member of Institut Lean France. Specialist in Obeya and product development expert for the digital world.
Cécile Roche: Lean sensei, member of the Institut Lean France, Lean Director of the Thales Group,
