Today’s blog post will take a deep dive into Toyota thinking and principles, to really understand the meaning of them. It will then soon be evident why not Lean is mentioned instead of Toyota, in this blog post’s name. This is an important matter since both Toyota Production System and Toyota’s product development* are built on Toyota thinking. But what we today call Lean, is only built on the former, the Toyota Production System. And many are the methods and frameworks today. Especially agile ones, that are built on this Lean production thinking, but used for product development, which is cumbersome, especially for large-scale agile, since production is not product development.
Kanban is one of the more obvious methods related to Toyota, but also Scrum is built on Japanese and Toyota’s thinking. The word Scrum, to describe product development, is first to be find in the HBR article “The New New Product Development Game” from the January 1986 HBR issue [1]. From this article, Ken Schwaber and Jeff Sutherland derived not only the term Scrum, but also their thinking of small teams in their Scrum Development Process [2]. This is fine for small scale, but will be deeply problematic at scale**, since some scaling frameworks leaning on agile thinking, proclaim that the Product Owner role is scalable, which it in most cases is not**, especially not for novel products or systems. Also, the DevOps thinking is indirectly taken from the Toyota Production System, since its foundation is derived from Lean [3]. For a deep dive into the HBR article as well as a fulfilment of our set of principles, see this series of blog posts. There are also other tries to lean on Lean; Lean 3.0, Lean Knowledge Systems, Lean 4.0 and Lean UX, where no one of them is even close in understanding Toyota’s thinking and principles, and where also Lean UX according to complexity theory, still is not more than a linear process [4]. Adding feedback loops will simply not make it proper for taking care of complexity, since uncertainty and complexity is two different things.
Since Toyota do not use the term Lean, this series will instead use the thinking, values and principles from the concepts of Toyota, all to avoid unnecessary intermediates corrupting the original message like in the children’s game Chinese whispers. Instead, we will go to the source, Gemba or Genchi Genbutsu, which are the Japanese expressions.
Today it is very easy to find information by just google the internet, for the good and the bad. The good is that it is easy to find information, but the problem is to judge right from wrong in the answers we get. Since Toyota’s work normally is considered synonymous with Lean, why do we not just google the common expression “House of Lean” to get the pillars of the Lean thinking, you suggest. But instead that is a one-way track we should not enter, because if we google “House of Lean”, there is innumerable different depictions and interpretations of the original Toyota thinking. And that is why we need to remove as many intermediates as possible between us and the source. But if we google “TPS House” that is less well-known, but that has been around for at least one more decade than the “House of Lean”, we still get many depictions and interpretations. There are also other “houses” adding pillars like Flow and Innovation, which are only symptoms (consequences) to the organisation’s way of working, i.e., they should definitely not be there, since we only want the basic principles. If we add these pillars, we have really not understood Toyota thinking and we will most probably try to optimise on them instead, even though they are symptoms of our way of working. But once again, trying to fix symptoms means sub-optimisation.
So, in this case, googling the internet is simply not good enough, meaning we need to go and see at the source for ourselves, at Toyota. The best source we can get is their own book; Toyota Production System: an integrated approach to just-in-time, fourth edition, from 2012 [5]. And since Toyota’s thinking journey never stops, we realise ourselves that the first edition of the book from 1988, really won’t do the job today, since more than four decades (in Japanese already 1978) have passed. So, the information about the TPS (House) in the remainder of this series is only taken from this fourth edition, also backed up by their current global homepage [6].
The Toyota Production System (TPS) was established based on the two concepts Jidoka (autonomation, originating from the common sense of finding problems fast and solve them fast) and Just-In-Time (only produce what is needed and using takt time, originating from the common sense of that planning is always needed), which are the pillars of the TPS house. Other important concepts are Shojinka (flexible work force) and Seiko (yes, Seiko as in Seiko clocks), or to go forward (creative thinking or inventive ideas), see page 8 [5].
Furthermore, TPS also focuses on supporting and encouraging people to continually improve the process that they are working on and clearly shows that Toyota values their people. In 2001, Fujio Cho, a former Toyota president, published The Toyota Way model*** [7], a management approach for the whole of Toyota, to further emphasise the important role that Toyota’s people play in the journey for always becoming better. This is also many times depicted as a house with the pillars Respect for People and Continuous Improvement****, which readers of the non-spread 14 pages of the internal Toyota Way paper, have concluded as not being enough for building the total organisation [8]. This is because these two pillars focus more on the principles for the people side, as a complement to the pillars that TPS is built on, Jidoka and Just-In-Time, that focuses more on the hard side, especially the latter one. But still the people side is important as well and could be put, and sometimes are put, between the pillars in the TPS House to get a high focus, since it is self-evident that Toyota considers their people as the most important asset. Putting everything together, we have six necessary and non-interchangeable pillars as Toyota’s principles, for building a wholeness; Just-In-Time, Jidoka, Just-In-Time, Respect for People and Continuous Improvement****, and the important concepts of Shojinka and Seiko, which all of them will be elaborated on in the continuation of this series. If we put it all together in a “TPS House” it looks like this, The TPS House:
Just-In-Time
Just-In-Time is the same as planning, to get an activity ready exactly when next process or team in turn is ready to continue adding value to the activity. In TPS, Just-In-Time is not only about planning in order to get a high Flow Efficiency, but also quality, healthy people, etc. With the repetitive work that a production context is, Toyota has found out over many decades that planning the production with takt time is the most efficient. This is combined with very short cycles to bring up any problem to the surface as fast as possible, according to Jidoka, the second of the conceptual pillars of the TPS house.
Of course, it is a very big difference between waterfall product development in projects that is knowledge work with non-repetitive, long cycles of months, and production that is repetitive with a takt time of minutes. Inside the time-boxes the work is also very different with many long-term non-plannable interdependencies to other teams in product development, and with only a clear hand-over between the processes next to each other in production. But we still have the same repetitive planning pattern, with phases/disciplines or processes with different I-competence and a handover between them. The similarities of sequential work between TPS and waterfall development is further explained in this blog post.
What also is important to point out, is that it is the same Critical Path***** thinking for projects with waterfall and TPS, which means that if an activity on the Critical Path***** is delayed, that means directly a decrease of the Flow Efficiency.
For Agile development there is no explicit Critical Path*****, instead Business Value is sometimes used for the stories handled by the different agile teams. That means that it is acceptable that activities regarding stories with low Business Value can be placed in the queues on the Kanban board, but not the activities that regards stories with high Business Value, since then the Flow Efficiency decreases. This also goes for stories with high Business Value that are ready within the sprint, but that is ready earlier than the time-box of the sprint, since that generates bad Flow Efficiency as well. And when an activity is ready, but there is no one there to continue with the activity, that is frankly not Just-In-Time, meaning that Agile is not following the pillar Just-In-Time, the planning pillar. The same goes when scaling agile, since then there will always be dependencies and interdependencies between the teams and to experts and supporting functions, due to the fact that the agile teams cannot simply have all the knowledge within the team itself. This is especially valid regarding wholeness considerations like systems design, but also regarding law, safety, security as well as other non-functional requirements. If these dependencies and interdependencies are not planned, Just-In-Time is per se not fulfilled. This is a common problem when scaling agile, since long- and middle-term planning seldom is done, giving severe problems. See also this blog post for more detailed explanation of Just-In-Time, Pull and Push, where all three are used in Toyota’s production.
Jidoka
The concept of Jidoka means to find a problem fast with as little human interaction as possible and autonomation is the translation of Jidoka. On page 434 [5] we can read; “Production lines can be stopped by workers when problems occur on the line….. In the Western world, it is referred to as empowerment“. This is a very important aspect, since in this way, the workers with Jidoka, Continuous Improvement**** and Seiko (inventive ideas), are gaining freedom and power over their own situation, since they know that their voices are not only heard, but the way of working will continuously be better.
The word Jidoka itself, is invented by Toyota from the word automation, with the same pronunciation as the word automation, but with different spelling in Kanji due to the added connotations of humanistic and creating value. The importance of problem-solving, can be found in this famous quote found also in the Toyota Way from 2001 [7], by one of the former Toyota CEOs, Eiji Toyoda:
A person’s life is an accumulation of time – just one hour is equivalent to a person’s life. Employees provide their precious hours of life to the company, so we have to use it effectively, otherwise, we are wasting their life.
The evolution towards Jidoka can be seen as this production example;
- Manual feed into a machine and manual ejection from the machine by an operator that at the same time is watching the machine
- Automatic feed to the machine and automatic ejection and the operator is only watching the machine
- Automatic feed and automatic ejection and that the machine is self-monitoring itself with an Andon light showing the status of the machine, meaning that an operator can watch many machines at the same time
And as we can see, the thinking behind Jidoka is the important aspect, not Jidoka or autonomation itself. The thinking is to find and solve any problem as fast as possible, which is valid for any context, not only production. Instead, contexts that are complex, like product development, will give considerably more symptoms depending on human flexibility trying to fix the symptoms, if we not solve our problems directly.
A clear implementation of Jidoka cannot only be seen in production, another good example is testing of software, where we during the last decades has gone from only manual testing, test case by test case, to today’s continuous day-and-night-testing of new code. This means that an alert is immediate if a test case fails, and the problem-solving can start directly.
Remember though, that Jidoka is only to find the fault, but not to solve it, which we can see both in production and software testing, since we still have not come to the point yet, where the machines or programs also fix the problems for us.
And with this said, that Jidoka actually is not fixing the problem for us, we need to be even more vigilant, because we have so far not talked about what problems we should take care of with Jidoka. It is easy to think that Jidoka is only bringing up problems within our products or services, but it regards all kind of issues and problem and this is stated about Jidoka [5], page 225;
“Respect for humanity: Since quality control based on autonomation calls immediate attention to defects or problems in the production process, it stimulates improvement activities and thus increases respect for humanity.”.
The natural way for Toyota to take care of problems is by using the 5 why? technique, to find and eliminate the root cause(s), see this blog post for a thorough explanation of the 5 why? technique. This means, as stated many times in earlier blog posts, that if we find a problem, we always need to ask why we have the problem, and for Toyota this has always been self-evident and a truly success factor. Asking why is valid for any problem, no matter if it is a problem within our product or an organisational problem with the way of working. If we not try to find the root cause(s) by asking why, we will only try to solve symptoms, which means sub-optimisation. For a thorough explanation and many examples of how to solve both product and organisational problems, see this series of blog posts on how to boost your problem-solving abilities.
How Agile and frameworks built on Agile are dealing with problem-solving will be brought up in the Continuous Improvement**** pillar in the next blog post, so you need to persist until then.
This was all for today’s blog post. C u tomorrow in part number two, where we continue with the people side pillars, Respect for People and Continuous Improvement****, before we end this series with the conclusions in the third and last blog post.
*But, even though both contexts, production and product development within Toyota, are built on the same thinking, the contexts are very different, with very different way of working. This means that their respective culture is different too, since culture is a consequence (symptom) of the system, see this blog post for a deep dive.
**But, beware that the “The New New Product Development Game” article, states about project teams, or team of teams, not single teams, which means a misinterpretation and loss of the whole. This means especially that the need of a Product Owner (PO) at team level for a sub-product, strongly can be questioned, since it is easily leading to a separation of the problem-solving part of the wholeness as well as the loss of the Big Picture for respective team. The PO role in Scrum has always been for one team, and has never been stated as scalable (which it is not, since the architecture’s subsystem isn’t followed exactly when instead making epics, features or user stories in Agile). And of course, also that the PO becomes more of a coordinator of smaller and smaller activities, to make the PO a full-time resource, not to mention the filter between the customer and the team as well as a bottle neck and single point of contact. But, since many companies haven’t got a properly implemented portfolio, especially regarding prioritization and decision making, that is really the work for a real Product Owner that owns a total product, a PO per team is unfortunately often seen as a solution to this problem (symptom). Unfortunately, since symptoms are insolvable, it instead creates more symptoms messing up the system, instead of doing the only thing that can be done; solve the root cause and introduce a Product Owner for the total product, with mandate to take decisions regarding the product.
***The coming years after 2001, The Toyota Way was broken down according to context to philosophies (methods) for the individual divisions in their different booklets; “The Toyota Way in Sales and Marketing”, “The Toyota Way in Accounting & Finance”, “The Toyota Way in Personnel and Labor Relations”, “The Toyota Way in Purchasing”, “The Toyota Way in R & D” etc.
****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.
*****which has been generated transdisciplinary and iteratively with the project team and its sub-teams, common experts, stakeholders, centralised resources etc., i.e., taking also resource constraints for the total organisation into account.
References:
[1] Takeuchi, Hirotaka and Nonaka, Ikujiro, ”The New New Product Development Game”. Harvard Business Review, Jan 1986 issue.
Link copied 2018-09-05:.
https://hbr.org/1986/01/the-new-new-product-development-game
[2] Sutherland Jeff, Schwaber, Ken. “SCRUM Development Process”.
Link copied 2019-09-06.
http://www.jeffsutherland.org/oopsla/schwapub.pdf
[3] Onbird. Blog post. Link copied 2019-09-09.
https://onbird.se/devops-and-the-three-ways/
[4] Snowden, Dave. Blog post. Link copied 2018-07-05.
https://cognitive-edge.com/blog/causal-effect-through-engagement/
[5] 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.
[6] Toyota global homepage. “Toyota Production System”.
Link copied 2019-07-12.
https://global.toyota/en/company/vision-and-philosophy/production-system/
[7] Toyota global homepage. “Compilation of the Toyota Way”.
Link copied 2019-09-06.
https://www.toyota-global.com/company/history_of_toyota/75years/text/leaping_forward_as_a_global_corporation/chapter4/section7/item4.html
[8] Baudin, Michel. Blog post. Link copied 2019-09-07.
Michel’s summary in the blog post:
“My read on it is that it is misleading for readers who are just starting their Lean implementation in that they may believe that all they have to do is continuous improvement with respect for people.”
https://michelbaudin.com/2013/06/13/94306-8/