Is Agile a Subset of Lean Manufacturing?

If you hang around agilists long enough, someone will mention lean manufacturing, Toyota Production System or Kanban. Since these concepts predate Agile, you might wonder how they relate, and perhaps why lean manufacturing wasn’t directly applied to software (until perhaps recently with Lean/Kanban). You might wonder whether Agile is just a subset of Lean Manufacturing.

What is Lean Manufacturing?

Lean Manufacturing, sometimes called Just-in-Time manufacturing or Toyota Production System (TPS), originated in post-World War II Japan to cope with low cash, limited warehousing space, few natural resources and high unemployment. It emphasized driving waste out of the manufacturing cycle. Toyota’s definition of waste includes items we don’t normally consider—such as inventoried parts, “work in process,” variable work load—as well as the usual defects, product returns and overbuilding [Muda, Muri, Mura].

Lean manufacturers look very different from historic American assembly lines, which emphasized repetition, motion analysis and economies of scale. Toyota instead promoted greater autonomation, the philosophy that repetitive activities should be done by machines, while thinking and creative activities should be done by humans. So Toyota’s factory floors included more robots, employing humans in teams to assemble complex systems, analyze problems and devise solutions. Since American assembly lines exploited speed and employee utilization, Americans rarely stopped the assembly line. In contrast, Toyota workers ceremoniously pulled an andon (“paper lantern”) cord to announce discovery of a defect: conveyor belts stopped, managers made their way to the location of the pulled cord, and then workers and managers rapidly performed root cause problem analysis, devised a short-term fix and initiated a plan to permanently avoid the problem.

Lean Manufacturing fueled Toyota’s rise and dominance from almost nothing. It produced only about 2000 passenger vehicles between 1933 and 1947. By 1984, Toyota was producing about 4 million cars per year, virtually all in Japan. Under pressure to produce cars in the USA and fearful that it did not understand American workers, Toyota partnered with General Motors to use lean manufacturing in GM’s shuttered Fremont factory, which had a history of antagonism, sabotage and drug use. Toyota wanted to experiment with “the real thing,” dismissing GM’s suggestion they find other workers, and rehired the motley crew. After Fremont employees were trained in TPS, the factory showed dramatic improvements in quality and profitability; it produced the highest quality cars GM offered [This American Life, NUMMI (26 March 2010)]. Other GM plants failed to apply the approach (which still stupefies me), and GM declared bankruptcy in 2010. Ironically, GM closed the Fremont plant for good the same year. As if Fremont is the location of some strange singularity, Tesla, today’s most cutting edge mass production car manufacturer, bought the Fremont plant in 2010 and now produces its cars there.

I study lean manufacturing and its many contributions to our society. Some will note how many agile practices arise from lean manufacturing. In fact, agilists even see the same stupefying management behavior, such as reversing agile practices despite overwhelming data showing Agile’s superiority in their own organizations. Agile stole freely from lean manufacturing, and virtually all agilists acknowledge its power. Agile and Lean Manufacturing are pals who share a lot of toys.

But is Agile a Subset of Lean Manufacturing?

Recently a colleague asked me whether Agile was a subset of Lean Manufacturing. Could lean manufacturing people produce an agile software transformation? I’m a “big tent” agile guy. The Scrum Alliance designates me as a Certified Enterprise Coach, but I’ve often spoken at Lean/Kanban conferences. Lean/Kanban folks include many “quants,” like me: people interested in data and statistics. Anyone who seeks to measurably produce better products for more beneficiaries can hang out in my tent. So if reality makes Lean Manufacturing the big daddy of Agile, I’m cool with that.

But Agile and Lean Manufacturing (not to mention software development and manufacturing) are different. Someone armed solely with a lean manufacturing background is extremely unlikely to produce a successful agile transformation, unless they embrace agile practices that are outside lean manufacturing and understand how Agile promotes creativity.

Agile and lean manufacturing both take action “just-in-time,” but they support different things. One supports innovation, the other supports optimization. Unfortunately, sometimes those goals conflict.

The article that led Jeff Sutherland and Ken Schwaber to invent Scrum, the dominant Agile methodology, is Hirotaka Takeuchi and Ikujiro Nonaka’s, “The New New Product Development Game,” Harvard Business Review (Jan 1986). This article compares product design to the fast-moving, barely-controlled game of rugby. It sparked a revolution, so most agilists know of it.

Scrum and Agile practices focus on product development (i.e., design) rather than manufacturing. Scrum supports creativity, learning and innovation rather than analysis, waste reduction and control. For example, the article discusses the six characteristics of designing products in this new way:

1. Built-in instability
2. Self-organizing project teams
3. Overlapping development phases
4. “Multilearning”
5. Subtle control
6. Organizational transfer of learning

Here’s how Wikipedia describes lean manufacturing:

Lean manufacturing or lean production, often simply “lean”, is a systematic method for the elimination of waste (“Muda”) within a manufacturing system. Lean also takes into account waste created through overburden (“Muri”) and waste created through unevenness in work loads (“Mura”). Working from the perspective of the client who consumes a product or service, “value” is any action or process that a customer would be willing to pay for.

Essentially, lean is centered on making obvious what adds value by reducing everything else. Lean manufacturing is a management philosophy derived mostly from the Toyota Production System (TPS) (hence the term Toyotism is also prevalent) and identified as “lean” only in the 1990s. TPS is renowned for its focus on reduction of the original Toyota seven wastes to improve overall customer value, but there are varying perspectives on how this is best achieved. The steady growth of Toyota, from a small company to the world’s largest automaker, has focused attention on how it has achieved this success.

Note that key line, “lean centers on making obvious what adds value by reducing everything else.” Lean applied in isolation doesn’t generate innovative designs fast, because its focus is to remove variation, randomness and the unexpected. Creative activity, where we design and build something never built before—exhibited more or less in virtually all product development—introduces variation inherently. Creativity and unpredictability often go together; the more innovative a creative act is, the more variability it produces. When careless lean advocates measure and control variation without leaving room for natural variation in creativity, they may throw out the baby with the bathwater.

Agile and Lean practices can work well together, when their contributions are respected—waste is created in software development (technical debt, manual testing, component team dependencies, etc.) and lean manufacturing strategies can help. In fact, virtually all Scrum courses include material on Kanban, Theory of Constraints and A3, which come from lean manufacturing. If lean manufacturing strategies dominate, however,  creativity and innovation, key aspects of software development, can suffer.

Very recently, “Lean Startup” appeared on the scene (2003 “Four Steps to the Epiphany” by Steve Blank, and 2011 “Lean Startup” by Eric Reis). Lean Startup accelerates innovation by discarding the idea that we have to create something with customer value, and that instead we seek market learning value first. Lean Startup is radical, and its application has created modern, constantly-experimenting behemoths such as Facebook. By learning more about the market, we waste less effort creating products people won’t likely buy or use. One could argue that “Lean Startup” is just a “very big lean manufacturing,” and from that newly expanded vision I might have to agree. However, lean manufacturing texts did not include the waste of “not meet customer demand or specifications” until [Womack 2003]. because they focus on designs that are already largely completed. 

Some agilists push Lean/Kanban, which is an adaptation of lean manufacturing for IT, as a software development practice. Lean/Kanban emphasizes none of Takeuchi and Nonaka’s six characteristics. Despite having appeared 40 years before Agile, lean manufacturing has gained little hold in software development. However, Lean/Kanban appears to work well for IT operations (configuration and deployment) activities. I attribute this to the lower need for innovation in operations.

When colleagues advocate Lean/Kanban in software development, and especially if they are transitioning from Scrum, I always ask them to institute a metric-driven rhythmic retrospective (which I discuss here), and ask them to compare their Kanban results to their Scrum results over time. Without a rhythmic retrospective, I have found Lean/Kanban to be difficult to sustain; I want organizations to help more people with higher quality products for a long time. I’ve seen some sad unravelings of agility when people selectively adopt Lean/Kanban practices; but when people include metric-driven Retrospectives, it seems to last and improve more rapidly.

With historic data supporting Agile, managers take significant risk when they contemplate turning back the clock, even for something as agile-friendly as lean manufacturing. Waterfall projects fail at a rate of about 29% and Agile projects fail at 9%; waterfall succeeds 14% of the time and agile succeeds 44% of the time; the rest are “challenged projects” that partially achieved their goals and are being used (Standish Group Chaos Report). 

This is the third time I’ve read the Takeuchi and Nonaka paper. Every time I do I find a new subtlety or insight. I’m surprised how prescient it was. It’s an easy read, and I’d invite you to read it yourself.

You might ask yourself, “Is Lean a subset of Agile?” I sometimes wonder that myself.

There is nuance here, I really do apply lean manufacturing techniques daily in my Agile work, and I welcome alternative views. If you comment, I’ll happily respond.