I wrote a rant against the idolization of Lean and Toyota among certain
DevOps people.
Originally it was the synopsis for a more thorough article which I don't
have the time to write, so instead I present only the conclusions. Maybe
of interest to people here involved in programming (or union work and
working conditions, for that matter) since DevOps is everywhere these
days and has its good sides too.
https://blogs.fsfe.org/agger/2022/05/12/devops-inspiration-from-toyota-prod…
DevOps inspiration from Toyota Production System and Lean considered
harmful
*Note: This text was originally the synopsis for a much longer article
which I intended to write as the followup to a lightning talk
<https://hackmd.io/@DgwTpN18RPqYa3pK_-o2eA/B1gGTzZ1c#/> about the
subject I did at my workplace. Acknowledging that I probably won’t get
time to write the long version, I think this synopsis can stand pretty
well on its own as a statement of intent.*
DevOps and DevOps-related practices has become a huge thing in the
software industry. Elements of this, such as Continuous Integration and
Continuous Deployment and the focus on monitoring production systems and
metrics has resulted in large improvements in the handling of
large-scale deployments. Especially, the act of deployment to
production, in traditional systems often an error-prone process riddled
with cataclysmic pitfalls and requiring huge amounts of overtime, is
reduced to the trivial pushing of a button which can easily be done in
normal office hours.
While the success of DevOps largely rests on technological improvements
(containerization, orchestration systems, ease of scaling with cloud
technologies) as well as process improvements originating in the Agile
methodologies as they have developed since 2001 (with concepts such as
pair programming, Test Driven Development and a general focus on
automatization), much of the literature on DevOps contain a strong
“ideological”, to the point of evangelization, promotion of the
underlying philosophies of Lean production and management systems. One
very conspicuous feature of this ideology is the canonization of
Japanese management methods in general and the Toyota Production System
(TPS) in particular as an epitome of thoughtful and benign innovation,
empowering workers by incorporating their suggestions, achieving
world-class production quality while simultaneously showing the maximum
respect for each and every one of the humans involved.
This method (the TPS) was, the story goes, introduced in Western
manufacturing and later in management, where its basic principles –
improvement circles (kaizen), value stream mapping, Kanban, etc. has
streamlined the basic business processes, improved productivity and
reduced costs. Now, the narrative continues, DevOps will apply these
same Lean lessons in the software industry, and we can expect similar
vast improvements of productivity.
It is problematic, however, to try to “learn from Toyota” and from Lean
Manufacturing without examining in detail how these work in practice,
not least how they affect the people actually working in those systems.
The authors behind some of the more popular DevOps introductions – The
DevOps Handbook and the novels “The Phoenix Project” and “The Unicorn
Project” – do not seem to have actually studied the implications of
working under the TPS for Toyota’s Japanese employees in great detail,
if at all, and seem to have all of their knowledge of the system from
American management literature such as James Womack et al’s “The Machine
that Changed the World”, basing their own Lean philosophies entirely on
Toyota’s own public relations-oriented descriptions of their system.
This is problematic, since it overlooks the distinction between Toyota’s
corporate representation of the intention of their production system –
and the actual reality felt by automobile workers on the shop floors.
Darius Mehri, who worked at Toyota as a computer simulation engineer for
three years, has pointed out that the Western management movements
inspired by Toyota have failed to understand a very fundamental
distinction in Japanese culture and communication: The distinction
between /tatemae/ (that which you are supposed to feel or do) and
/honne/ (that which you really feel and do). Mehri posits that all
Western proponents of The Toyota Way fail to realize that what they are
describing is really the /tatemae/, what management will tell you and
what workers will tell you in a formal context when their words might
come back and harm them – while the /honne/ is much grittier, much
darker and much more cynical.
In effect, proponents of Lean manufacturing and management styles have
imported a kind of double-speak in a Japanese variant, but similar to
the all too well-known difference between corporate communcations and
what workers will confide in private. By doing so, they have inherited
the fundamental lie that the priorities of the TPS are respect for each
individual employee, partnership between management and workers, and
involvement of each and every employee in the continuous improvement of
the workplace; while its true priorities are a maximization of profit
through the imposition of frenetic work speeds and very long working
hours, discarding workers afflicted by the inevitable accidents and
work-related diseases – and an “innovation” mainly driven by imitation
of other manufacturers.
The truth about the very Toyota Production System that inspired the Lean
movement is, leaving the /tatemae/ aside and looking at the /honne/,
that these factories are driven unusually ruthlessly, with little or no
regard for the human costs for the workers on the shop floor. Meetings,
security briefings and announcements are routinely made after or before
actual working hours, when workers are on their own time. Assembly lines
are run at extreme speed in order to increase productivity, resulting in
serious accidents, chronic work-related diseases as well as production
defects. Even so, production targets are set unrealistically high, and
the shop crews are not allowed to go home before they are met, often
resulting in several hours of daily overtime. The “improvement circles”
do exist and workers are indeed asked to contribute, but the end goal is
always to increase production and increase line speed, never to create
more humane working conditions on the shop floor. Such improvements are
(if at all) introduced more grudgingly, e.g. as a consequence of labor
shortages and worker dropout.
Lean, by lauding the TPS and uncritically buying its /tatemae/, is
introducing a similar /honne/ of its own: It is, in reality, /not/
revolutionizing productivity, and for all its fair words does /not/
promote the respect of each worker as an individual. On the contrary,
the relentless focus on constant “improvements” and constant demand that
each employee rationalizes their work as much as possible has caused it
to become known as “management by stress”. It may indeed focus on
metrics and may indeed choose metrics to demonstrate its own success –
while achieving results that range from average/no change to absolutely
dismal.
Proponents of DevOps should /stop/ presenting Toyota as any kind of
ideal way of working – literally, a nightmarish grind with workers
forced to do ten- or eleven hour shifts, ignoring accidents, running
beside old and worn-out machinery in outrageously dangerous conditions
is /not/ where we want to go. And the “ideal Toyota” with its
“improvement kata” and “mutual respect” never existed except as the
/tatemae/ to the cynical /honne/ of shop-floor reality. By importing the
/tatemae/ as though it were Truth itself, the Lean movement has imported
its double-speak – Lean or “management by stress” transitions can be
very unpleasant indeed for employees, and while everything is shrouded
in talk of partnership and mutual respect, the underlying motivation
will often be money-saving through layoffs – the /honne/ to the Lean
management bullshit’s /tatemae/.
That is to say: Perpetuating the lie about Toyota as a humane,
innovative and respectful workplace is /positively harmful/ to the
employees and processes afflicted by the proposed improvements, as the
double-speak involved will inevitably rub off. The Toyota /tatemae/ was
not, after all, designed to be practised literally. Accepting it at face
value will only set us up for further double-speak in our own practice.
While the software industry can and should continue to evolve based on
the philosophy enshrined in the Agile Manifesto
<https://agilemanifesto.org/> and the improved work processes introduced
by DevOps, we should eschew the mendacious narrative of Happy Toyota and
reject the Lean philosophies that it founded.
REFERENCES
Heather Barney and Sheila Nataraj Kirby: /Toyota Production System/Lean
Manufacturing/ in “Organizational Improvement and Accountability:
Lessons for Education from Other Sectors”, RAND Corporation 2004
(online: https://www.jstor.org/stable/10.7249/mg136wfhf.9
<https://www.jstor.org/stable/10.7249/mg136wfhf.9>).
Ian Hampson: /Lean Production and the Toyota Production System – Or, the
Case of the Forgotten Production Concepts/, Economic and Industrial
Democracy & 1999 (SAGE, London, Thousand Oaks and New Delhi), Vol. 20:
369-391 (online:
https://library.fes.de/libalt/journals/swetsfulltext/6224179.pdf
<https://library.fes.de/libalt/journals/swetsfulltext/6224179.pdf>).
Jeffry S. Babb, Jacob Nørbjerg, David J. Yates, Leslie J. Waguespack:
/The Empire Strikes Back: The End of Agile as we Know it?/, paper given
at The 40th Information Systems Research Seminar in Scandinavia: IRIS
2017 – Halden, Norway, August 6-9, 2017 (online:
https://research-api.cbs.dk/ws/portalfiles/portal/58521158/IRIS_2017_critic…
<https://research-api.cbs.dk/ws/portalfiles/portal/58521158/IRIS_2017_critic…>)
Darius Mehri: /The Darker Side of Lean: An Insider’s Perspective on the
Realities of the Toyota Production System/, Academy of Management
Perspectives *20*, 2, 2006 (online: https://www.jstor.org/stable/4166230
<https://www.jstor.org/stable/4166230>)
Stuart D. Green: /The Dark Side of Lean Construction: Exploitation and
Ideology/, proceedings IGLC-7, 1999, 21-32 (online:
https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.22.323&rep=rep1&t…
<https://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.22.323&rep=rep1&t…>)
Satoshi Kamata: /Japan in the Passing Lane: : An Insider’s Account of
Life in a Japanese Auto Factory/, Pantheon Books, New York (1982)
Gregory A. Howell and Glenn Ballard: /Bringing Light to the Dark Side of
Lean Construction: A Response to Stuart Green/, proceedings IGLC-7,
1999, 33-38 (online:
https://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=203907F7926472DB3…
<https://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=203907F7926472DB3…>)
Will Johnson: /Lean Production – inside the real war on public
education/, Jacobin Magazine, December 2012 (online:
https://www.jacobinmag.com/2012/09/lean-production-whats-really-hurting-pub…
<https://www.jacobinmag.com/2012/09/lean-production-whats-really-hurting-pub…>)
Mike Parker: /Management-By-Stress/, Catalyst Magazine /1/, 2, 2017
(online:
https://catalyst-journal.com/2017/11/management-by-stress-parker
<https://catalyst-journal.com/2017/11/management-by-stress-parker>)
Gene Kim, Jez Humble, Patrick Debois and John Willis: /The DevOps
Handbook/, IT Revolution Press, Portland (OR) 2016.
Gene Kim, Kevin Behr and George Spafford: /The Phoenix Project/, IT
Revolution Press, Portland (OR) 2015.
Gene Kim: /The Unicorn Project/, IT Revolution Press, Portland (OR) 2019.
Phil Ledbetter: /Why Do So Many Lean Efforts Fail?/,
https://www.industryweek.com/operations/continuous-improvement/article/2114…
<https://www.industryweek.com/operations/continuous-improvement/article/2114…>,
20/9-2020.
Enid Mumford: “Sociotechnical Design: An Unfulfilled Promise or a Future
Opportunity”,
https://link.springer.com/content/pdf/10.1007/978-0-387-35505-4_3.pdf
<https://link.springer.com/content/pdf/10.1007/978-0-387-35505-4_3.pdf>
Hello everyone,
the Bits&Bäume Conference is a conference on the subject of digital
sustainability and it took place in 2018 for the first and only time so far.
This year however there will be the next edition of Bits&Bäume and this time
the FSFE is part of its organising committe. We are only one of many
organisations, but our goal is of course to have many interesting topics
around Free Software in connection with digital sustainability.
You can find the call for participation here:
https://bits-und-baeume.org/konferenz/en
Registration deadline: June 7th
The text of the call for participation is quite long, but you will see that
this is true because there are actually many different ways to participate.
Lectures and workshops can be submitted, but also art and science, conceptual
gatherings or other creative forms of activity. "Start-Ups" also have the
opportunity to present themselves to a jury in a "Pitch and Thrive".
As you can see, the format is really very open to contributions and I would be
very happy if we could see a lot of Free Software topics being covered on the
different stages : )
And while I can't help you to get your submission through, I am happy to help
if you have any questions or want feedback on whether your format might be of
general interest or not. Feel free to ask me directly about it. And also feel
free to distribute this mail further on any other list from that you think
there are people who will be actually interested in it.
Questions and ideas of general interest could be for example
* Lectures on different dimensions of the sustainability of Free Software
(technical, economical, social ...)
* Your favorite Free Software that contributes to sustainability
* A piece of hardware that you were able to give a new life to with the help
of Free Software or extended usage time
* Increased resource efficiency of your computer through free software
* Organizational sustainability through the use of free software and Opener
Standards
* Sustainable knowledge management and and and
Best regards,
Erik
--
No one shall ever be forced to use non-free software
Erik Albers - Programme Manager Digital Sustainability
Free Software Foundation Europe (FSFE)