Merriam-Webster Dictionary defines Agile as \u201chaving quick resourceful and adaptable character, or marked by ready ability to move with quick easy grace.\u201d<\/p>\n\n\n\n
Lean is defined simply as \u201cthin and healthy, or containing little or no fat.\u201d<\/p>\n\n\n\n
Based on these definitions, we can assume that someone who is lean and someone who is agile could have many shared characteristics. The same is true in the context of software development.<\/p>\n\n\n\n
Looking to hire the best remote developers? Arc can help you:<\/em><\/p>\n\n\n\n \u26a1\ufe0f Get instant candidate matches without searching Try Arc to hire top developers now \u2192<\/strong><\/em><\/a><\/p>\n\n\n\n Agile<\/strong> is now widely known in the technology world as a set of values and principles to guide the development of software. \u201cThe Agile Manifesto<\/a>\u201d lays out a set of four values and 12 principles. <\/p>\n\n\n\n Distilled to its core, Agile is exactly what you think it might be. It\u2019s Agile<\/em>. The methodology favors flexibility<\/strong>, communication<\/strong>, collaboration<\/strong>, and simplicity<\/strong>.<\/p>\n\n\n\n Lean<\/strong> is less understood and lacks a clear-cut definition supported by a professional consensus. The term \u201cLean\u201d was originally coined to describe a manufacturing organization model based on the Toyota Production System but is commonly considered a sub-framework within the Agile umbrella of software development.<\/p>\n\n\n\n Today, there is much confusion about what is Lean, what is Agile, if they are one and the same, and which should be used.<\/p>\n\n\n\n Read More<\/strong>: How to Network: a Guide for Remote Software Developers & Engineers<\/a><\/p>\n\n\n\n Both Lean and Agile were developed in response to the shortcomings of existing plan-driven methods like Waterfall. Used since the 1970s, developers and software engineering managers began to notice the inefficiencies of Waterfall by the 90s. With more dynamic markets and tech-savvy consumers, Waterfall was unable to respond quickly enough to market demands, change technology, or deliver bug-free software consistently.<\/p>\n\n\n\n In pursuit of a better model, the creators of Lean and Agile sought to develop methodologies with a more customer-focused approach<\/strong>. The new methodologies embraced the ability to adapt as a competitive advantage, favored early and continued testing, and brought a human element into project management and execution.<\/p>\n\n\n\n Lean Software Development<\/strong> (LSD) was first proposed by Dr. Robert Charette as a way to build change-tolerant organizations that were becoming increasingly dependent on software.<\/p>\n\n\n\n Next came \u201cThe Agile Manifesto\u201d which enshrined the 12 principles of Agile Software Development<\/strong>.<\/p>\n\n\n\n The other authoritative work on software development methodologies is credited to Mary and Tom Poppendieck, who published Lean Software Development: An Agile Toolkit.<\/em><\/p>\n\n\n\n Here is a side-by-side comparison of the values and principles of each:<\/p>\n\n\n\n Comparing the 12 principles of Dr. Charette\u2019s LSD and the 12 principles of Agile, you can see that they are strikingly similar. The seven Lean principles proposed by the Poppendiecks are less targeted but nevertheless overlap with \u201cThe Agile Manifesto\u201d and Charette\u2019s Lean Software Development.<\/p>\n\n\n\n Here are more elements they all have in common:<\/p>\n\n\n\n Read More<\/strong>: Here Are 21 of the Best Online Developer Communities to Join<\/a><\/p>\n\n\n\n We\u2019ve investigated the watershed events and publications that gave birth to these terminologies to see how they became popular. Check out our timeline below detailing the progression, and add these to your reading list if you are so inclined!<\/p>\n\n\n\n As you can see from the timeline, the term Lean was first used by Womack et. al. in 1990 to describe the Toyota Production<\/strong> System in their book, The Machine That Changed The World<\/em>. Dr. Robert Charette later adapted Lean ideas described in earlier publications to create his \u201cLean Software Development\u201d.<\/p>\n\n\n\n The term Agile was not was not widely adopted until the publishing of \u201cThe Agile Manifesto\u201d in 2001. The terms Agile and Lean were both coined by western technology professionals or academics who were referencing the Toyota Production System (more on this later).<\/p>\n\n\n\n We might catch some flak for saying so, but with this in mind, the terms Lean and Agile are not actually that<\/em> important. Having two terms stemming from the same principles actually contributes to confusion on the subject. That being said, this is the terminology the industry has adopted, so moving forward we will continue to use them.<\/p>\n\n\n\n The timeline is also another source of confusion. Dr. Robert Charette introduced his ideas on Lean Software Development<\/strong> in the early and mid-90s. The tactical purpose and 12 principles of his Lean Development approach were described in 1998 in an article titled, \u201cLean Development,\u201d nearly three years before the \u201cThe Agile Manifesto.\u201d <\/p>\n\n\n\n In a testament to the overlap between Lean and Agile, this article was written by Jim Highsmith, who later became a core founder of the Agile movement. However, Highsmith\u2019s article was not widely circulated, and it wasn\u2019t until 2003 that Charette himself wrote a more in-depth explanation behind his lean development approach in the research report, \u201cChallenging the Fundamental Notions of Software Development.\u201d<\/p>\n\n\n\n Read More<\/strong>: Here\u2019s When You Can TRULY Call Yourself a \u201cSenior\u201d Software Developer<\/a><\/p>\n\n\n\n In an email exchange with Dr. Charette, he was quick to point out that his conception of Lean Development was intended for the organizational level within the software field:<\/p>\n\n\n\n Mine was borne out of a strategic as well as operational need to improve IT\u2019s business\/mission value to the organization, and I approached this from a management of risk perspective.<\/p>\nDr. Robert N. Charette<\/cite><\/blockquote>\n\n\n\n This differs slightly from Agile<\/strong>, which was first proposed strictly as a \u201cbetter way of developing software,\u201d but now is applied to various projects and management methods.<\/p>\n\n\n\n 2003 was also the year the Poppendiecks published Lean Software Development: An Agile Toolkit. This book detailed seven principles of Lean Development, which correlate directly to the seven forms of waste in Lean Manufacturing.<\/p>\n\n\n\n The Poppendiecks\u2019 book simultaneously bolstered Lean as a software development methodology and blurred the distinction between Lean and Agile, by proposing Lean as a complementary method within Agile. In fact, at the time of publishing, the book was sold as the latest publication within The Agile Software Development Series<\/strong>.<\/p>\n\n\n\n Today, the Poppendiecks\u2019 multiple works on the subject are considered essential reading for Lean, and \u201caspiring-lean\u201d software development practitioners.<\/p>\n\n\n\n Read More<\/strong>: 5 Ways to Stand Out & Get Noticed in Your Current Development Job<\/a><\/p>\n\n\n Arc is the best place to find great remote jobs. Find great remote jobs at top startups and tech companies. Freelance and full-time remote opportunities are available. According to Dr. Charette, one of the primary differences between Lean and Agile is that Agile is bottom-up, while Lean is top-down. This is evident in Lean\u2019s end-to-end (E2E) structure and the principle of See the Whole proposed by the Poppendiecks. Below we explain these principles at work in the practice of value stream mapping.<\/p>\n\n\n\n To realize the principle of See the Whole<\/em>, the Poppendiecks detail a method of value stream mapping to reveal the value-added activities versus the non-value added activities throughout the end-to-end development process.<\/p>\n\n\n\n Value stream mapping analyzes the development cycle from the time a requirement is received to the time it is delivered to the customer. The goal is to identify the wastes of sitting inventory and waiting (delays in production), and explore new practices to reduce Work-in-Progress (WIP) and lead time.<\/p>\n\n\n\n According to the Poppendieck\u2019s, mapping your value stream is a simple exercise that only requires a pencil and a piece of paper. The process is as follows:<\/p>\n\n\n\n The Agile paradigm as laid out in \u201cThe Agile Manifesto\u201d favors short iteration cycles<\/strong> and frequent deliveries<\/strong> over a holistic end-to-end view. The E2E focus is therefore unique to Lean. In fact, it is because of the E2E construct that Lean (rather than Agile) is more often applied as an organizational structure and management style.<\/p>\n\n\n\n The end-to-end view necessitates that the whole organization takes part in order to eliminate waste. This echoes Dr. Charette\u2019s stated purpose for his original Lean Development concept:<\/p>\n\n\n\n Lean Development is a philosophy, a way of seeing and thinking about IT and its relationship to an organization, as much as it is a development approach.<\/p>\nDr. Robert N. Charette<\/cite><\/blockquote>\n\n\n\n Read More<\/strong>: How To Use Social Media Thought Leadership To Level Up Your Developer Career<\/a><\/p>\n\n\n\n Both Lean and Agile have adopted the TPS Kanban system with slight variations. Toyota\u2019s Kanban system<\/a> was designed to limit Work-in-Progress.<\/p>\n\n\n\n As opposed to traditional \u201cpush manufacturing,\u201d which pushes inventory to the next step in the process, Kanban only pulls new material into production once the current piece has been processed and components need to be replenished.<\/p>\n\n\n\n Kanban cards become resupply orders and are sent back to the previous step in production. As a result, Work-in-Progress is minimized, and idle inventory is reduced.<\/p>\n\n\n\n In software development, instead of passing Kanban cards from one manufacturing step back to the previous one, a Kanban board is used. Sticky notes are used, most often to represent requirements in progress.<\/p>\n\n\n\n According to the chapter contributed by Kai Petersen in Modern Software Engineering Concepts and Practices: Advanced Approaches<\/em>, both Agile and Lean use a prioritized list of requirements to pull tasks from.<\/p>\n\n\n\n Unlike Agile, which uses fixed duration iteration cycles to limit the time of development and govern the Kanban board, Lean limits the number of tasks allowed at any given time. This allows Lean to fulfill its primary goal of limiting WIP, while more accurately measuring lead-time, and identifying waste in production. Once a task is completed, a new one can be pulled from the prioritized list. While Lean uses the concept of continuous flow, Agile begins each new iteration with a fresh board.<\/p>\n\n\n\n Some teams recognize the benefits of both approaches and are beginning to use a hybrid method known as scrumban<\/a>.<\/p>\n\n\n\n These are just two of the subtle differences in the approach Lean and Agile take to achieve common goals. In practice, whether your team takes a so-called \u201cAgile\u201d approach or a \u201cLean\u201d approach is unimportant. What\u2019s important is finding the right practices to optimize your workflows and consistently deliver value to your customers, which both methodologies see as the ultimate purpose.<\/p>\n\n\n\n Read More<\/strong>: Do You Need a Computer Science Degree to Get a Job in Software Development?<\/a><\/p>\n\n\n\n So what does this all have to do with the Toyota Production System<\/strong>? Pretty much everything. The creators of both Agile and Lean were heavily influenced by TPS, as Womack et. al. describe in The Machine That Changed the World<\/em>. <\/p>\n\n\n\n To better understand the inspiration for Lean and Agile methodologies, we will take a look at the manufacturing system developed in Japan between the 1950s-70s, specifically:<\/p>\n\n\n\n Warning:<\/p>\n\n\n\n The rest of this article contains jargon that you can use to sound scholarly after reading.<\/p>\n\n\n\n Following WWII, Toyota was on the brink of collapse with a damaged supply chain and depression-level demand for their automobiles. The company could not hope to follow a Detroit model of mass production and survive.<\/p>\n\n\n\n Under these conditions, Taiichi Ohno and Kiichiro Toyoda set out to remain profitable by eliminating waste in production, reducing lead time, and only producing what customers needed, also known as Just-in-Time<\/strong> (JIT) manufacturing.<\/p>\n\n\n\n To eliminate waste, Ohno resolved to make only what was needed, when it was needed, and only in the amount it was needed in.<\/p>\n\n\n\n The iterative process of Lean and Agile which focuses on minimizing feature development, and maximizing delivery of updates directly mirrors Toyota\u2019s Just-in-Time manufacturing.<\/p>\n\n\n\n Read More<\/strong>: 8 Great Benefits of Working From Home (A Guide for Remote Developers)<\/a><\/p>\n\n\n\n Jidoka (\u81ea\u50cd\u5316) can be translated as automation with a human touch, sometimes referred to as \u201cintelligent automation.\u201d Jidoka plays a major role in eliminating waste in production by making machines more independent which frees up people to play a more active role in the production and unlocks human creativity.<\/p>\n\n\n\n Jidoka relies on intelligent machines that stop automatically when there is an irregularity. Human workers can then go and fix the problem, stopping defects from being passed down in the production process.<\/p>\n\n\n\n Jidoka also empowers every employee to stop the production line when a problem is detected. The principle includes a four-step process to eliminate the waste of defective products:<\/p>\n\n\n\n You can see the Jidoka concept in the Lean and Agile focus on early and frequent testing to root out bugs, and emphasis on customer consultation to pinpoint user pains.<\/p>\n\n\n\n To achieve JIT manufacturing, Taiichi Ohno outlined seven forms of waste to be eliminated. Number eight was added later. If you take a closer look at Agile and Lean\u2019s values, goals, and principles, you can see that they are designed to guard against the eight wastes of TPS. In their 2003 book Lean Software Development: An Agile Toolkit<\/em>, the Poppendiecks presented TPS wastes in a software development context.<\/p>\n\n\n\n 1. The Waste of Overproduction<\/strong>. The waste of overproduction is one of the biggest reasons the Waterfall method has been abandoned. Overproduction is considered extra coding for features that weren\u2019t requested and that the customer may not want.<\/p>\n\n\n\n This is reflected in the following principles:<\/p>\n\n\n\n Agile \u27f6 simplicity<\/strong> Charette\u2019s Lean\u27f6 minimalism<\/strong> Poppendiecks\u2019 Lean \u27f6 eliminate waste<\/strong><\/p>\n\n\n\n 2. The Waste of Waiting<\/strong>. In JIT manufacturing, waiting on an idle machine or worker is wasteful. In software development, waste is waiting on a team with excess capacity. If there are delays in production that cause a team to be on standby, or cause the customer to wait for delivery, there is waste.<\/p>\n\n\n\n Matching principles are as follows:<\/p>\n\n\n\n Agile \u27f6 frequent cycles<\/strong> Charette\u2019s Lean \u27f6 \u2153 of the time (goal of LSD), 80% solution today<\/strong> Poppendieck\u2019s Lean\u27f6 deliver as fast as possible<\/strong><\/p>\n\n\n\n 3. The Waste of Transportation<\/strong>. In software development, transportation is translated as \u201ctask switching\u201d. Too many handovers or employees assigned to multiple teams with a demand for excessive multitasking is inefficient and a waste.<\/p>\n\n\n\n Matching principles:<\/p>\n\n\n\n Agile \u27f6 stakeholder collaboration, self-organizing teams, culture of trust, support, and motivation<\/strong> Read More<\/strong>: Software Developer vs Software Engineer vs Computer Programmer<\/a><\/p>\n\n\n\n 4. The Waste of Overprocessing<\/strong>. This is simply extra processes that aren\u2019t really needed to deliver value to the customer. The primary example is documentation. Excessive documentation for inflexible processes will not be valuable, nor are overly detailed user manuals which could be summed up in a page or two. Documentation is time-consuming yet offers limited value to the end-user.<\/p>\n\n\n\n Matching principles:<\/p>\n\n\n\n Agile \u27f6 simplicity, working software as the measure<\/strong> Charette\u2019s Lean \u27f6 minimalism<\/strong> 5. The Waste of Inventory<\/strong>. Inventory waste is Work-in-Progress for which an investment has been made, but holds no value until completion. In other words, incomplete software provides no value to the user. Lean and Agile value fast and frequent deliveries, with an emphasis on frequent iterative cycles and delivery of working software.<\/p>\n\n\n\n Matching principles:<\/p>\n\n\n\n Agile \u27f6 customer satisfaction<\/strong> (through early and frequent customer delivery) Charette\u2019s Lean \u27f6 80% solution today<\/strong> Poppendieck\u2019s Lean \u27f6 deliver as fast as possible<\/strong><\/p>\n\n\n\n 6. The Waste of Movement<\/strong>. Waste of movement is excess effort required to get information or answer questions. This is common when teams are not co-located, if tasks are completed and results are not made available immediately to all relevant parties, or when stakeholders are not readily available for consultation.<\/p>\n\n\n\n Matching principles:<\/p>\n\n\n\n Agile \u27f6 stakeholder collaboration, face-to-face communication<\/strong> Charette\u2019s Lean \u27f6 customer participation, team effort<\/strong> Poppendiecks\u2019 Lean \u27f6 eliminate waste<\/strong><\/p>\n\n\n\n 7. The Waste of Defects<\/strong>. Like in manufacturing, producing defective or buggy software represents a wasted investment by the company. The quicker a defect is detected, the more likely waste is mitigated. Many Agile and Lean principles seek to halt the waste of defects. To reduce defects, all three methodologies place a premium on early and frequent testing.<\/p>\n\n\n\n Matching principles:<\/p>\n\n\n\n Agile \u27f6 technical excellence, working software as a measure<\/strong> Charette\u2019s Lean \u27f6 customer satisfaction<\/strong> Poppendiecks\u2019 Lean\u27f6 amplify learning<\/strong><\/p>\n\n\n\n 8. The Waste of Unused Employee Creativity<\/strong>. In software development, unused creativity results from a rigid roadmap and lack of human collaboration. Just like Jidoka (\u81ea\u50cd\u5316), Agile and Lean seek to maximize human cooperation and innovation to get the best results out of technology.<\/p>\n\n\n\n Matching principles:<\/p>\n\n\n\n Agile \u27f6 stakeholder collaboration, team reflection<\/strong> Charette\u2019s Lean \u27f6 \u201cunwritten\u201d 13th principle of satisfaction through work<\/strong> Read More<\/strong>: When Can You Stop Calling Yourself a \u201cJunior\u201d Software Developer?<\/a><\/p>\n\n\n\n Many of the core values that make up TPS are also reflected in Agile and Lean software development methodologies.<\/p>\n\n\n\n Kaizen (\u6539\u5584)<\/strong> translates as continuous improvement. With flexible, iterative, customer-focused models, continuous improvement is perhaps the most important value of Agile and Lean software development methodologies.<\/p>\n\n\n\n Hansei (\u53cd\u7701)<\/strong> means self-reflection. As a means to improve efficiency, The Agile Manifesto directly adopts team self-reflection<\/strong> as its 12th principle. In introducing his Lean Development model, Dr. Charette challenges readers to reflect on all of the current assumptions that dictate the processes they use as an initial step to finding better ones. The Poppendiecks\u2019 amplify learning<\/strong> principle can be considered Hansei as well.<\/p>\n\n\n\n Respect for People (\u5c0a\u91cd)<\/strong> is central to all three paradigms. The first value of \u201cThe Agile Manifesto\u201d is to \u201cvalue individuals and interactions over processes and tools.\u201d<\/p>\n\n\n\n Respect for people also appears in Dr. Charette\u2019s assertion of the importance for individuals to experience satisfaction through work<\/strong>, and the Poppendiecks\u2019 Lean principle of empowerment of teams<\/strong>. This value recognizes that when individuals are involved in decision making and improving their work environment, they are more innovative and efficient workers.<\/p>\n\n\n\n Seiri (\u6574\u7406)<\/strong> is the principle that mirrors waste. Seiri dictates that what is unnecessary should be removed. This encompasses all of the original seven wastes of TPS, for which we have already identified the parallel waste in the software development environment.<\/p>\n\n\n\n Gengchi Genbutsu (\u73fe\u5730\u73fe\u7269)<\/strong> literally translates to \u201cactual place, actual thing.\u201d In practice, this means \u201cinspect to understand.\u201d When there is a problem in the production process, the manager should go to the source to understand the problem and determine how to solve it.<\/p>\n\n\n\n In software development, this value is manifested in the emphasis on short iteration cycles, early testing, and customer collaboration so that software engineers can build working software that users actually want.<\/p>\n\n\n\n Read More<\/strong>: 15+ Most Popular Programming Languages & Technologies to Know\/Learn<\/a><\/p>\n\n\n\n As we mentioned in the opening paragraphs of this post, Lean methodology is less well understood and is often considered to be an Agile practice. Lean is perhaps less well-defined simply because of its broader applications.<\/p>\n\n\n\n Lean has a more direct relationship with the Toyota Production System and was first proposed as an organizational set of methods and practices for business management, and only later applied to software development. Agile, on the other hand, was developed specifically for software development by dedicated<\/a> professionals in the field.<\/p>\n\n\n\n After detailing the shared background and general principles of these two methodologies, you can see that these two paradigms have more in common than they have differences.<\/p>\n\n\n\n One of the primary authors of \u201cThe Agile Manifesto,\u201d Martin Fowler, who has also worked closely with the Poppendiecks, has pointed out that Lean and Agile are not mutually exclusive:<\/p>\n\n\n\n Lean and Agile are deeply intertwined in the software world. You can\u2019t really talk about them being alternatives\u2026.you don\u2019t do Agile or Lean, you do Agile and<\/em> Lean.<\/p>\nMartin Fowler<\/cite><\/blockquote>\n\n\n\n You can also explore HireAI<\/a> to skip the line and:<\/em><\/p>\n\n\n\n \u26a1\ufe0f Get instant candidate matches without searching <\/em><\/strong><\/em><\/strong><\/a>Try HireAI and hire top developers now \u2192<\/a><\/em><\/strong><\/em><\/strong><\/p>\n","protected":false},"excerpt":{"rendered":" This article introduces the principles, origins of, and differences between Lean and Agile software development methodologies. <\/p>\n","protected":false},"author":4,"featured_media":1562,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3,12],"tags":[],"class_list":["post-1555","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-career-growth","category-insights"],"yoast_head":"\n
\u26a1\ufe0f Identify top applicants from our network of 350,000+
\u26a1\ufe0f Hire 4x faster with vetted candidates (qualified and interview-ready)<\/em><\/p>\n\n\n\nWhat is Agile? <\/h2>\n\n\n\n
What is Lean?<\/h2>\n\n\n\n
The Birth of New Software Development Methodologies<\/h2>\n\n\n\n
Lean vs. Agile principles<\/h3>\n\n\n\n
![\"what's](\"https:\/\/arc.dev\/talent-blog\/wp-content\/uploads\/2022\/04\/lean-vs-agile-principles-and-goals-1024x836.png\")
<\/figure>\n\n\n\n\n
Timeline<\/h2>\n\n\n\n
![\"agile](\"https:\/\/arc.dev\/talent-blog\/wp-content\/uploads\/2022\/04\/evolution-of-software-development-methods-timeline-1024x751.png\")
<\/figure>\n\n\n\nOrigins of Lean and Agile<\/h3>\n\n\n\n
\n
![\"work](\"https:\/\/arc.dev\/talent-blog\/wp-content\/uploads\/2024\/10\/Talent-blog-CTA-banner.png\")
<\/figure><\/div>\n\n\n
Sign up here<\/strong><\/a><\/p>\n\n\n\nDivergence in Application<\/h2>\n\n\n\n
Value Stream Mapping<\/h3>\n\n\n\n
\n
\n
Lean Kanban Vs. Agile Kanban<\/h3>\n\n\n\n
The TPS Connection<\/h2>\n\n\n\n
\n
Just-in-Time Manufacturing<\/h3>\n\n\n\n
Jidoka<\/h3>\n\n\n\n
\n
![\"\"](\"https:\/\/arc.dev\/developer-blog\/wp-content\/uploads\/2022\/02\/Meet-HireAI-blog-CTA-banner-1024x256.png\")
<\/a><\/figure>\n\n\n\nWastes of TPS in a Software Development Context<\/h3>\n\n\n\n
Charette\u2019s Lean \u27f6 team effort<\/strong> Poppendiecks\u2019 Lean \u27f6 empower the team<\/strong><\/p>\n\n\n\n
Poppendiecks\u2019 Lean \u27f6 eliminate waste<\/strong><\/p>\n\n\n\n
Poppendiecks\u2019 Lean \u27f6 amplify learning<\/strong><\/p>\n\n\n\nTPS Values in Software Development Methodology<\/h3>\n\n\n\n
Conclusion<\/h2>\n\n\n\n
\n
\u26a1\ufe0f Identify top applicants from our network of 350,000+ with no manual screening
\u26a1\ufe0f Hire 4x faster with vetted candidates (qualified and interview-ready)<\/em><\/p>\n\n\n\n