Is Lean 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- and Lean 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.
Lean manufacturing floor
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.
In 1984, 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.
Since 2012, Toyota has produced more cars and more profit than any other car maker worldwide.
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, and virtually all agilists acknowledge lean’s power. Agile and Lean Manufacturing are pals who share a lot of toys.
But is Agile a Subset of Lean?
Recently a colleague asked me whether Agile was a subset of Lean. 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 wants to produce better products for more beneficiaries is in my tent. So if reality makes Lean 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 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 to England,” Boocal.
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:
- Built-in instability
- Self-organizing project teams
- Overlapping development phases
- “Multilearning”
- Subtle control
- 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 software 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 over time. Without a rhythmic retrospective, I have found Lean/Kanban to be difficult to sustain, and 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.
Comments (10)
Dave Diehl
As a another big tent agile guy that agrees with much of your post, some thoughts
If you are taking a kanban approach, you should be committed to limiting WIP, measuring cycle times, and gathering data. I’m all for the metric driven retrospectives (if that’s what you mean).
I disagree with this. I don’t think removing variation hinders creativity at all. When I read variation, I think about unexpected work and outages that cause teams to miss commitments. Software teams that miss commitments are often given a short leash to innovate on.
In my experience, software teams that meet commitments can then work with the customer to innovate more and be more creative. The intent behind kanban is to help reduce variation in work to help create satisfied customers and workers that are not overburdened. Whether it delivers on this promise is another blog post, but that’s the ide.
If I misunderstood you in my comments, feel free to note that as well.
On variation, I added more clarification and care to my statement, but I stick with my claim. “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 software 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.”
Dave, I assume you and I are responsible folks who would not let variation control stop creativity, however when applied in large organizations it’s easy for unsubtle people to create disasters. For example, at 3M: http://www.zdnet.com/article/six-sigma-killed-innovation-in-3m/
Regarding Lean/Kanban and retrospection, of course it includes Kaizen, introducing small, incremental improvements as the system operates. However, I have not seen rhythmic retrospection advocated in Lean/Kanban (except perhaps by me). I don’t advocate Sprint Planning or Review (which would turn Lean/Kanban into Scrum) necessarily, but the discipline of a rhythmic retrospective is something often missing from Lean/Kanban. In my opinion, it should be front-and-center.
Jeff Sutherland
The first Harvard Business Review paper on Scrum in 30 years will be published soon. It will be titled “Embracing Agile” and focus on Scrum as the leading agile implementation. Prof. Takeuchi and I will coauthor the paper with Darrell Rigby, the leader of Bain Consulting’s Innovation practice.
At a Lean Enterprise Institute meeting, the CEO John Shook pointed out that Takeuchi and Nonaka were looking at Lean Product Development at Toyota when they defined Scrum in their 1986 HBR paper. He also agreed that Lean is a western concept based on manufacturing practices done on the assembly line at Toyota. But he points out these are implemented by cross-functional teams, which are Scrum teams. So it really is Scrum everywhere.
However, most people implementing Scrum are not Lean, much less a Takeuchi and Nonaka Scrum, and that causes them not to have working software at the end of a sprint. Thus they are Agile “in name only,” not meeting the second value in the Agile Manifesto.
Agile is a superset of lean. It was defined at the Agile Manifesto meeting based on a book, “Agile Competitors” which discussed 100 lean companies that had become Agile by involving the customer directly in product development.
Thanks for this great background, Jeff. When your article is live, let us know and we’ll review it here.
Jeff Streitmatter
“However, most people implementing Scrum are not Lean”… love it!
William Langhorne MIller
Other references in 1986 described the creation of new practices that were “agile” development such as Barry Boehm’s spiral process for software development.
https://en.wikipedia.org/wiki/Spiral_model
However, practices existed before 1986 that applied an iterative process of learning similar to the process in agile development such as the OODA loop used in aerial combat in WWII. OODA loop refers to an iterative rapid process to rapidly learn and then react to events. The process in OODA is observe-orient-decide-act.
https://en.wikipedia.org/wiki/OODA_loop
Both lean start-up methodology (LSM) and agile development are subsets of the fourth generation (4G) of innovation management which was first applied in 1978 to create modern software engineering that was introduced at Microsoft in the early 1980’s. 4G innovation and 4G R&D were both described in publications beginning in the 1990’s.
4G has a nested set of iterative processes that are necessary to effectively create radical innovation that is based on new 4G dominant designs and that transforms markets and industries for sustained economic growth.
It’s been my claim that Scrum introduced two big ideas: rhythm and retrospection not incorporated in either Boehm’s Spiral Model or the OODA loop. Rhythm insists that the team operate in Boehm’s spiral model in a fixed time period, thus forcing the entire team to invoke collective responsibility to deliver on time. Retrospection effectively has the team review past experiments (aka Sprints), define its new process for the coming Sprint, hypothesize metric outcomes, and control the experiment (via a ScrumMaster).
Al Shalloway
I would suggest this is the wrong question. A better question is “Is Agile a subset of Lean-Thinking” which gives a different answer. Lean-Manufacturing is Lean-Thinking applied to manufacturing. There are many things about software development that are not present in the physical world (emergent design much more possible, can’t see work in software to extent can in physical world, others).
We should consider what Lean-Thinking applied to business development with a software component is (IT or product development). Over a decade ago I demonstrated that 100% of Scrum (still the leading Agile framework) can be 100% described as a sub-set of lean thinking.
Not all of business development with a software component is, however a subset of Lean-Thinking. But that’s a different discussion.
Ken Eakin
The question of whether or not Agile owes much to Lean Manufacturing is a question that has been nagging at me for a while.
It is important to start with the facts. What is now called “Lean” has a long history, going back to the ideas of Fredrick Winslow Taylor and Henry Ford and earlier. It matured at Toyota in the 1950s and 1960s, one of many Japanese companies that learned from Deming and Juran’s ideas in the post-WWII era. Lean as a business term was coined only in 1988 and became more widespread with the book The Machine That Changed The World in 1990. At around the same time (late 80’s/early 90’s), the writings of Taiichi Ohno and Shigeo Shingo were translated into English for the first time. Deming’s New Economics book was published in 1993. In 1995, Womack and Jones published their landmark book Lean Thinking. As Jeff Sutherland points out above (via John Shook), Takeuchi and Nonaka were intimately acquainted with Toyota’s Production System and its product development process when they wrote their article coining the term Scrum (note this was before the term Lean came into existence!). Generally North American industry (manufacturing, primarily) was paranoically interested in Japanese productivity and quality in the 1980s.
Agile as a term, as I understand it, came into existence in 2001 (via the now famous manifesto). So Lean both as a practice and a philosophy predates Agile. I have a hard time believing that Lean ideas did not have a strong influence on predecessors like XP, Scrum and other software development methods in the 1990s before they were grouped under the Agile umbrella. I would suggest that Agile thinking/ideas are heavily indebted to the ideas of Lean (“Lean Thinking” as Al Shalloway points out). In practice Agile methods tend to be applied to software and have the (somewhat unproven) potential for being beneficial to new product (non-software) development. Lean methods tend to be used in ongoing operations and have found the most successful application in manufacturing and healthcare but have the (somewhat unproven) potential for being beneficial in other industries, including so-called “white-collar” knowledge work.
What irks me is that Agilists are (mostly) loathe to admit that Agile thinking owes anything to Lean thinking. Because Lean connotes blue-collar assembly line work, as well as things like “process” (meaning “rigid documented rules” in the software world), efficiency (aka work faster!), standardization (more rigid rules) and so on, it is rejected (perhaps out of snobbery and definitely out of misunderstanding) by so-called “knowledge workers”. This is a mistake.
I’m a “big tent” Lean guy and I think Agile thinking and Lean thinking are very much aligned– the best of both should be brought together. They are both humanistic, progressive management philosophies. Agile is perhaps more suited to new product development (NPD) and Lean to operations. All companies need to be excellent at both! So Agile is not a strict subset of Lean but a similar way of thinking, with a different emphasis (NPD vs ops) and typically applied in different contexts in different functional areas. Can you have Agile HR or Agile Accounting or Agile Risk Management? Yes, just as much as you can have Lean HR, Lean Accounting, etc.
I would love it if Agilists just admitted that their ideas owe a lot to Lean thinking (which, yes, came out of manufacturing) but have been creatively and successfully adapted to a software development context. Leansters and Agilists still have so much to learn from one another!
Peter McDonald
In my reading Ken Eakin is on the mark or closest too it.
What I have read from many authors whether it is Womack or Shook or Rother is:
Lean is just a word in a book to try and summarise what was found when they studied the culture at a Toyota .
At its heart I have learnt is Lean has no tools ( some tools are an outcome of lean thinking)
It’s about solving problems or some would say Plan do study(check) act. However it’s key principle is customer focus whether it involves directly the customer or not is irrelevant Lean will involve the customer directly or not if it needs to solve the problem.
Lean is not about waste reduction it’s about solving problems from a customer perspective. What many forget is it is inclusive of innovation as well.
In software some people solved a generic set of issues using problem solving to come up with a manifesto. My challenge this has become enscribed as a set of tools rather than principles.
Most if not all tools in Agile are derived from manufacturing stand ups cross functional teams MVP all used in manufacturing.
My view is both lean and agile have become religions or a methodology. Overall I see agile is limited to its manifesto where lean is limitless it just solves problems ( or opportunities). Problems and opportunities are the just different sides of same coin.