FEATURE – Following a visit to a Toyota supplier in Japan, the authors reflect on the nature of kaizen and explain why we might be looking for it in the wrong place.

Words: Michael Ballé, lean author, speaker and executives coach; Benoît Charles-Lavauzelle, co-founder and CEO of Theodo; and Régis Médina, Lean IT Coach, Institut Lean France

Photo courtesy of JC Bihr.

A few months ago, we were standing on the shop floor of a stamping plant, at a Toyota supplier in Japan. We had travelled halfway across the world looking for kaizen.

One of us (Benoît) had committed to lean as a scale-up method for his fast-growing software company, working with another one of us (Régis, an agile coach and lean IT expert) to get kaizen started in his coding teams. The idea was to use Isao Kato and Art Smalley’s six points method: 1. discover improvement potential, 2. analyze current method, 3. generate original ideas, 4. develop an implementation plan, 5. implement the plan, 6. evaluate the new method (from Isao Kato & Art Smalley, Toyota Kaizen Methods, Productivity Press).

The Toyota supplier’s leanness was impressive: all machines were running and waste was really hard to find; people were at their stations, adding value; quality was tracked individually; there was not an inch of unused space in the plant, and yet everything seemed in place and readily available to operators, to support their standardized work. Toyota trucks picked up small quantities of every part every half hour. We even saw the hoshin kanri board, detailing the company’s challenges, objectives and how these dovetailed into functional departments. But there was no trace of structured kaizen.

As we continued to look around, we realized that not only all presses were working continuously, they were also working on very small batches to satisfy Toyota’s demand of small quantities of every part in every truck. We watched a tool change-over: a team of operators simultaneously changed the dies of several presses on a line and got them started again in a matter of minutes (less than 10, when in a normal factory this can take several hours) – with the first part coming out a good part. More amazing still, production started again after the change-over without the usual controls and parts checking: the operators trusted the quality of the first part.

We asked again about kaizen, and were met with bewilderment. “Kaizen is everywhere, all the time,” the company’s director eventually told us.

As we discussed what we’d seen, we agreed this had to be the case. There was simply no way a plant could run so well without constant kaizen. Having visited several press plants over the years, one of us (Michael) confirmed he had never seen such quality, such flexibility or such capital intensity. Clearly, engineering brute force can’t get you there – you need kaizen.

WHY SHOULD THIS MATTER TO AN APP DEVELOPER?

Back on his gemba, thinking hard about what he’d seen in Japan, Benoît had a sudden insight: app users want to move from one page to the next and get what they want (information, a service, purchasing a product, and so on) as quickly as possible. With this in mind, any page loading time is pure waste in the eyes of the user. How relevant would it be to do kaizen on page loading time since it tackles the most important form of waste, the one directly affecting the end user? Very, we believe.

When Régis and Benoît discussed this with Nicolas Goutay, one of Theodo’s team leaders, he agreed immediately. He mentioned that, in fact, users did complain about pages loading too slowly. In one project he’d been working on, certain critical pages took as much as six seconds to load. Quick research showed how much of a problem this was – just check out this infographic by Kit Eaton.

According to this paper, one in four people will abandon a page if it takes more than four seconds to load. Amazon reportedly estimates it can lose up to $1.6 billion in sales each year for a page load slowdown of just one second. These are impressive numbers.

Régis and Nicolas decided to tackle this issue on one specific project and set a target of maximum three seconds for the loading time – in real-life conditions, which means that the Internet speed of the users is part of the issue. They then started looking around for what tech giants like Twitter, Google, Facebook or The New York Times did and listed potential ideas for improvement. Then, working with Antoine Kahn, Alexandre Chaintreuil and the rest of the development team, they attacked the problem piecemeal:

• 2 seconds were saved by compressing files before sending them to the user’s navigator;

• 6 seconds were saved by eliminating unnecessary requests to servers;

• 4 seconds were saved by prioritizing content so that what is most important to users gets loaded first;

• 1 second was saved by optimizing backend code by charting its path and marking time, in order to better understand where exactly time was spent executing the code.

The latter exercise turned out to be particularly interesting since it enabled the team to better study its code, formulate hypotheses on its efficiency and test them. Two of these hypotheses paid off and took one extra second out of the process.

Throughout this improvement effort, a number of things became apparent. First of all, the six-step kaizen method was very useful to get started and as a scaffolding to define a concrete target. The approach can also help to set hypotheses and create an environment in which Benoît, as the CEO, and Régis, as the lean coach, could challenge the team further and keep them focused on exploring and understanding rather than solving the obvious problems and moving on.

Secondly, as the team grasped the problem, the formal structure of kaizen became less relevant, while the actual lean thinking of “studying and eliminating waste” increased in importance. Indeed, the team took it upon itself to consider every fraction of a second “waste” for the user, and to investigate where it came from, formulate hypotheses, test them and come up with countermeasures – in other words, kaizen.

Thirdly, this became very valuable to the CEO, who could then see the potential to spread this kind of thinking across the firm and turn it into a real differentiator for the apps it develops. This is genuine lean thinking in the Toyota tradition of considering “customer first, dealer second, manufacturer third”. At Theodo, Benoît was looking at user first, customer second and coders third. The effort made by coding teams to shave seconds off loading times would first benefit customers, make them happy and develop the individual coding skills of each developer (as well as Theodo’s overall capability to create better apps).

So, one could say we went to Japan looking for a kaizen “method”, but didn’t find what we were after. What we did find was learning. We realize now that the formal structure of kaizen is not the kaizen itself – the map is not the territory.

What we learned is that to sustain real kaizen we need to get better at:

1. Clarifying the intended gains: the Managing Director of the Japanese Toyota supplier was very clear on what kind of concrete gains he needed from kaizen and where these gains could be reinvested. When Benoît saw the potential gains at the company level of faster page loading time, this gave meaning to the entire effort and for the coders themselves who understood what they were being asked to improve.
2. Study waste, with measurements to discover what really happens: beyond clearing early obvious problems, the team’s true discovery was its method to mark time in the code execution and to study how code behaved time-wise, which led to formulating hypotheses and, in fact, learning more about code and coding.
3. Kaizen requires teamwork: the shared interest of the CEO, the lean coach, the team leader and the team members is what kept the effort going when things got difficult (studying code line by line). It’s also what made it all worth it in the end. The different perspectives brought in to tackle a technical issue allowed the team to look for new solutions.

Too many kaizen efforts remain at the formal organizational level: go through the steps, fill the problem-solving template, maybe change the “process.” Too often, they don’t go all the way to the real technical process point, where the user uses the product or service, where the tool touches the part, where the design actually performs the function. We learned that real kaizen first requires leadership to understand what typical problems – those “hard-to-do” things – will make a competitive difference and then communicate this to the teams, in order to involve their talent and passion in finding creative ways of doing things better. Kaizen can’t be programmatic. It has to start with the top management genuinely wanting to make things better for users and customers, and supporting teams in studying their own ways of working and what kind of waste could be taken out of those technical processes. This is how real improvement happens. This is how a company innovates.

_{THE AUTHORS}