Welcome back to the second part of this series about Toyota thinking, values and principles [1] [2] and how it has been misinterpreted, leading to a lot of problems, that most often remain unsolved. Today’s blog post will go through the people side of the pillars, Respect for People and Continuous Improvement*.
Respect for people
Respect is always needed all over today’s organisations, and has been Toyota leading value for a century. Therefor Toyota’s people can raise issues and problems regarding the products or organisation, on any level in the organisation, not only within the processes where they work.
When we respect our people, we get a healthy organisation, which makes the organisation long-term successful. Most of the organisations have respect as a value word, but still some of them are failing to live up to it, but unconscious about it. There are of course many examples of this, but one of them that is now fast establishing as the number one disrespectful manner, is when new methods and frameworks are introduced.
Why?
The reason is that the thinking is that the team members considers only the way of working within the team (their process), but not the wholeness, since the wholeness is left to the framework and the leaders outside the teams to take care of. This is a fatal misinterpretation of Toyota thinking. And if from beginning no why has been asked on the problems of the organisation, this means high risk that the new method or framework tries to solve symptoms, which we already stated to be impossible. Many of our people will see this and raise questions about problems not handled by the new framework. And if the leaders outside the team only looks at the rules of a descriptive framework, these appropriate questions may not have an answer, and will be dismissed or parked to later be forgotten. This has nothing to do with some people are reluctant to the change, rather that the change is not solving some problems, or worse, adds new problems. And the tragic thing is that people in the old organisation that never would have been promoted to higher level positions, now got these positions, due to that the bureaucratic tendencies that many new frameworks has, win out. And this happens before everybody realises about the consequences and the possibility to retrive the situation is since long gone.
This new kind of disrespect can already be seen today, and will increase tremendously, since many times new frameworks are introduced since the competitors have done it, not because the frameworks are solving the original problems that the organisation have, which should be the reason for the initiative for change. We can not copy someone else’s way of working, which is 101 complexity theory, if we ask Dave Snowden at Cognitive Edge.
Continuous Improvement
Today there are many different Continuous Improvement (CI) methodologies or strategies available and some of the most common ones are, with some of their tools within brackets:
- Lean Manufacturing – (tools: Kaizen, 5S, smoothing, standardisation, etc.)
- Theory of Constraints (TOC) – (tools: Evaporating cloud, Current reality tree, Future reality tree, Transition tree, Prerequisite tree)
- Six Sigma – (tools: FMEA, Statistical Process Control (SPC), Control charts, Sampling, etc.)
- Total Quality Management (TQM) – (Tools: Check sheet, Scatter diagram, Cause and Effect diagram, Pareto charts, SPC chart)
- Balanced Scorecard – (Tools: Continuous Improvement tools, Key Performance Index Tools, etc.)
- Lean Six Sigma – (tools: Value Stream Mapping, 5S, Kaizen, Poka-yoke, FMEA, etc.)
The CI methodologies use the PDCA (Plan-Do-Check-Act) cycle, DMAIC (Define-Measure-Analyse-Improve-Control) or another cycle in order to set goals and objectives for continuous improvements of the processes of the organisation. In order to be successful, the processes need to be stable, standardised and doing their job already from start, otherwise it will neither be effective nor efficient to do improvements. The number of improvements proposed by the employees at a big Toyota plant, can be as many as half a million per year, where up to 90% of them are executed and will become new improvements. Both numbers are astonishing.
And as we can see, Jidoka (to find problems fast) is very different from Continuous Improvement and that they also are totally non-interchangeable, since they do completely different things. But unfortunately, we almost always only hear about Continuous Improvement, which is especially valid for Agile development. So, most probably you already seen that this was coming; the misinterpretation of Jidoka made in Agile, which erroneously tries to include all problem-solving in Continuous Improvement. This means that Agile and frameworks built on Agile never asks why on the problems they have regarding their whole organisation. So, for example instead of solving the root cause to their Kanban board’s queue problems, they have introduced WIP Limits, which by the way is a big mistranslation of Toyota’s use of WIP Inventories, see this blog post for a deep dive. This means that the root cause(s) to the organisational problems can never be found, and in this case that the root causes to their queues can never be found. And since any organisation is complex as well, trying to solve symptoms means endless walking for the teams in the fitness landscape, which is a clear Walk in the Dark.
And like any other of the pillars in the TPS house, also Continuous Improvement get difficult when we have a big organisation in another context then production. Since for production, there is no difference having only one process (team) trying to make Continuous Improvements, or with many consecutive processes which is the normal, since there cannot be any sub-optimisation. The reason is that there are no interdependencies at all between any of the processes and the dependencies that exist are well-defined and constant hand-overs and only exist between a process and its predecessor and successor. If the Agile teams ask why on their problems, they still can only solve answers within the team itself, no organisational problems on the whole. This means that when we have an organisation and we are trying to optimise the teams (the parts), that is an inevitable sub-optimisation, 101 complexity theory once again.
See also this blog post for a further exploration about Continuous Improvement, from the series about Russell Ackoff’s Managers’ panaceas., showing that methods trying to solve symptoms can never work.
This was all for today’s blog post, and in tomorrow’s blog post, we will wrap up this series, by looking more deeply into scaling and make the final conclusions. Hope to c u then.
*remember that on the whole only continually improvements can be done, due to the synchronisation needed between the parts when the respective part’s improvements are executed at the same time, for example takt time change. The parts can (and must) themselves be continuously improved, as long as they do not affect another part.
References:
[1] Monden, Yasuhiro. 2012. Toyota Production System: an integrated approach to just-in-time Fourth Edition, CRC Press, Boca Raton, Florida, US
Page 8, misspell; it is shojinka, and not stotinka.
[2] Toyota global home page. Link copied 2019-07-12.
https://global.toyota/en/company/vision-and-philosophy/production-system/