The Modern Software Factory Meets the Toyota Way
Integrating Lean manufacuring principles into software development
23 August 2017
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
As I attend Scrum and Agile conferences, I often hear anecdotes about Toyota’s processes in some form or fashion. Unfortunately, most often these references are given by speakers who haven’t experienced the Toyota culture firsthand. In each case, the discussion gives a snippet of a Toyota (or Lean Manufacturing) principle without the necessary context. After sitting in on three such talks recently, I decided it was time for me to contribute to the knowledge base about how Lean manufacturing principles can be adopted into a software assembly process.
Prior to entering the utility industry six years ago, my previous employment experience was working for Toyota for 15 years as a senior developer for their assembly line production systems. This experience gave me firsthand exposure to the necessary practices and culture to implement the Toyota Way into software development. This is the first in a series of articles that I would like to deliver on implementing Lean Manufacturing principles into the software assembly process.
After a decade and a half of working with assembly line software, I now view software development as an assembly line with a mixture of IT team members and business owners handing off the software at different points during the assembly process. A developer creates a piece of software; it is checked, potentially reworked, and then sent either to the customer or to another part of the assembly process. These steps mirror the automotive assembly line worker who develops a piece of the automobile. That piece is then checked, potentially reworked, and sent to the customer or a downstream part of the assembly process. The close commonality between the two processes means that we can use many of the same concepts for a modern software factory. In fact, most of the Agile and Scrum principles were drawn from Lean Manufacturing.
One of the key principles of the Toyota Way is a concept called jidoka. Jidoka is best illustrated by an early scene from Toyota’s history. Prior to the company’s transition to automobiles, Toyota was a loom works. A major advancement for the company that propelled it beyond its competitors was the concept of jidoka. For decades, the loom process had involved a one-to-one correlation of loom worker to loom. Although the looms were becoming more and more automated, they still required a single operator dedicated to each individual loom. This was required because the looms could start to weave bad thread and someone needed to consistently watch the machines to detect whether the weave had gone bad and, if so, reset the machine.
Toyota’s major advancement, which revolutionized the industry, was an invention that forced the loom to break its own thread and thus stop itself if the weave went awry. The concept of jidoka was born – the idea that machines and technology would self-monitor for quality issues and not just alert but actually stop the assembly process so that a human could step in to fix and restart the process.
Jidoka can have a similarly groundbreaking impact on software development. Modern software editors and companion tools allow us to develop an automated work stream that checks and stops itself. As I speak to developers about unit tests, most agree that it is a good practice. But not all understand that the target that we are reaching for is a library of unit tests that can be run quickly and efficiently every time a software build is performed, and then stop the process if the thread breaks (the tests fail). Automated unit tests, automated UI tests, and code quality software are all tools that can help employ jidoka at different automated stages along the assembly process. This allows a company to transition from tasking testers with endless rounds of regression testing to truly focusing on testing the new functionality. Instead of primarily focusing on checking for code quality issues, testers can refocus on ensuring that the software meets the intended requirements.
At my current company, I am working with our development teams to fully implement jidoka. We first automated the end-to-end testing to catch failures at the last gate before code promotion. Next, we are moving further to the left of the development process. We have employed a software quality tool that “smells” the code for potential coding issues and prevents check-in upon failure. Moving even further into the upstream development process, we are employing the automated unit test libraries to run at the execution of each build and prevent check-in if the tests fail. Finally, we are working to employ a coding standard wrapper on our software development editors that alerts and even prevents code from being added if it would break some of our most important coding standards.
Most developers are reluctant at first about the adoption of these types of tools and quality gates. During my tenure at Toyota, I witnessed the implementation of similar quality gates throughout the assembly process. Jidoka was not viewed as an inconvenience but rather as a competitive advantage that allowed them to move more quickly and efficiently and have confidence that they were not introducing quality problems into the assembly process. As an organization’s software development culture changes and shares the “why” as well as the “how” with the development teams, they will also begin to see jidoka not as a hindrance but as a vital tool in the development process.
Next in this series I will present the concept of heijunka, or leveling the workload.
Current rating: 4.9 (9 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.