Lean vs Agile — The Alchemy of Development

Understanding Lean and Agile: A Comparative Overview

Kevin Cooper
9 min readSep 21, 2023

Now, there are combinations of Lean-Agile mindset in existence, such as SAFe, and there’s multiple flavors of Agile (Scrum, XP…), however there seems to still exist some confusion on what is Lean, and how it differs from the popular Agile ideology.

I found a medium blogger by the name of Thorbjørn Sigberg who wrote a very good and high-level article back in 2019 on Lean vs Agile vs Lean-Agile, which was the inspiration for me wanting to write on the same. Here however I would like expound and contribute some of my own thoughts on the matter, and provide additional details of my experiences relating to Lean and Agile.

The target audience for this article are those who are seeking a more granular approach on the mindsets but want to keep technical details abstracted out — for example I will not discuss the technicalities of value-stream mapping or the intricacies of tracking sprint velocity/burndown.

Both Lean and Agile aim to streamline processes and enhance efficiency through distinct but similar philosophies and practices.

Differences between Lean and Agile
Lean VS Agile at a very high level — Kevin Cooper on kevincooper.dev

1. Origins and Evolution of Lean and Agile

Lean is rooted in Manufacturing

The Lean methodology finds its origins in the manufacturing industry, particularly from the Toyota Production System (TPS). It was born out of the need to eliminate waste, optimize processes, and maximize value for customers. Over the years, Lean principles have transcended industries, making a significant impact in software development and beyond. There are also traces of Lean pre and post-World War II era manufacturing processes. It is a very interesting subject, and I recommend reading A Brief History of Lean (The Lean Enterprise Institute/LEI) and History of Lean (Six Sigma Study Guide)

Agile is born out of Waterfall

Agile, on the other hand, emerged as a response to the shortcomings of traditional, plan-driven methodologies like Waterfall. This, as mentioned in Thorbjørn Sigberg’s article referenced above, came about via the Agile Manifesto in 2001. Agile was a rallying cry for adaptability, collaboration, and delivering working solutions incrementally that was born from the pain of the current state of development. Twelve principles were created, and have since become the bedrock of modern software development practices.

Software Development Methods Timeline with Waterfall and Agile — Pilar Rodriguez on ResearchGate
Evolution of Lean Management — Angelo Riva on ResearchGate

2. At the intersection of Lean and Agile

Customer Value Prioritization

One of the fundamental areas where Lean and Agile converge is in their unwavering focus on customer value. Both methodologies place customers at the forefront and recognize that delivering solutions to meet real needs is the ultimate measure of success.

Continuous Improvement

Lean’s ‘pursuit of perfection’ and Agile’s commitment to iterative development both reflect a culture of learning and enhancement. In Lean, you may call the philosophy ‘Kaizen’ (改善- effectively 改 kai — change, revision; and 善 zen — as a virtuous state of mind) and in Agile you may leverage ‘sprints’ (iterative development cycles). Both are about evolving and refining processes to achieve higher levels of efficiency and effectiveness.

There’s no “I” in Team

Both Lean and Agile advocate for the importance of cross-functional teams and aim to maximize the value delivered to customers in this fashion.

3. Lean: Streamlining for Maximum Value

Lean methodology, rooted in the principles of efficiency and waste reduction, is very much like a fine-tuned machine. It’s about doing more with less and focusing on what truly matters.

The Eight Wastes, abbreviated here as TIMWOOD(T). The last T is often described as the “hidden” waste. — Kevin Cooper on kevincooper.dev

Embracing Simplicity — Less is More Philosophy

In the world of Lean, simplicity reigns supreme. It’s not about cramming features, but more about identifying and eliminating waste within the process. This usually means trimming unnecessary steps in development workflows, streamlining code, or even re-evaluating architectural designs to ensure they’re lean and purposeful. Tools used here could be Value Stream Mapping, or the 5-Whys for root-cause analysis.

Customer Value is at the center

Lean methodology has a critical emphasis on delivering value to the end-user. Tailoring solutions to meet customer needs is the usual byproduct. However — peel this back a layer. The true intent is to understand what truly matters to the customer and end-users. Once you evaluate what value is and looks like, and the most efficient way to deliver it, developers can focus their efforts on features and functionalities that provide the most of that value. This is the secret that, in my opinion, makes Lean a very powerful philosophy to embrace. This means that the Lean philosophy transcends each layer of the SDLC and organization — meaning you can move and place the pointer idea of “customer” and “value” at each layer of the workflow, even making the development team the customer in certain workflows, all to optimize the overall process and deliver value on the fundamental layer.

4. Agile: Flexibilty in a Fast-paced culture

Almost everyone has heard of Agile. It is often hailed as a revolution in software development that champions adaptability, collaboration, and expedited delivery. As most are familiar with it, I will try to keep the section short but informative towards the point of the article.

A simple, non-wheel graphic relating to the concept of Agile development and sprints — Kevin Cooper on kevincooper.dev

Agile’s focus is on Fixed-length iterations, called “Sprints”

Agile development most commonly operates on the principle known as sprints, which is atime-boxed approach to development batches. I like to think that the concept came from Jake Knapp, who wrote the famous book “Sprint”. To summarize, it introduces the concept of a “sprint,” which is a five-day framework designed to lead teams from ideation to prototyping and testing. The goal of a sprint is to gain valuable insights and validate or refine a concept in a short amount of time, making it an invaluable tool for startups and established companies alike. In real-world scenarios, there is usually a work board (Kanban) or post-its that is used to plan a set of features or tasks to be completed within a specific time frame. The idea is to keep the development malleable, and the time frames all adjust based on feedback.

Emphasis on Collaboration and Customer Feedback

Agile’s iterative nature (above) allows for a constant flow of feedback from stakeholders and end-users. This feedback loop ensures that the product evolves in line with changing requirements. This is crucial for Agile’s success.

5. Choosing the Right Approach: The Perfect Alchemy

The perfect mixture isn’t one or the other, per se. Each approach has their own strengths and weaknesses, which ultimately align to various aspects of your business or culture you are emphasizing. Let’s explore how combining Lean’s emphasis on efficiency with Agile’s adaptability could create the perfect mixture for success.

An important point to note is that there are other frameworks out there that attempt to impose a certain system — which is all fine and well, even when scaled across an enterprise — as long as you know what you’re getting into. I do not advocate for such frameworks and will instead defer to Lean’s simplicity — if it’s too complicated or too extensive, it should be revisited. The models of Lean and Agile can be applied in simplicity across layers or teams of an organization, and it doesn’t have to be as standardized as every other team within an enterprise. However, if there is an off-the-shelf framework that fits your organizational culture, then by all means feel free to invest there.

A generalization of some traits asociated with both Lean and Agile methodologies — Kevin Cooper on kevincooper.dev

Note that the above diagram makes generalizations for Agile such as “No commitment or prioritization” when it comes to a culture of CI or Innovation. This does not mean that there is never a commitment, it simply means that within the capacity of the project the weight of Culture does not prioritize or commit to process improvements via Lean, since the Culture may be weighted more on the product, MVP, or process output at a given time. In that case, even if the weight is well-defined, there would be more of a focus on an Agile mindset.

Where Lean Shines: Streamlined Processes for Well-defined Projects

Not all projects are created equal. Some are well-defined with clear objectives and predictable requirements. For such projects, Lean methodology excels. Its emphasis on efficiency and waste reduction ensures that resources are allocated precisely where they’re needed. By eliminating unnecessary steps and focusing on what truly matters, Lean ensures a streamlined development process.

Agile’s Edge in Complex, Rapidly-evolving Environments

On the other end of the spectrum are projects characterized by complexity and rapidly changing requirements. This is where Agile truly shines. Its iterative nature and emphasis on adaptability allow teams to respond swiftly to shifting priorities. Through fixed-length iterations, Agile enables the delivery of incremental value, ensuring that the end product aligns with evolving customer needs.

Final Take

Now, note that this isn’t the end-all-be-all recipe for how to use these mindsets. There is a lot more on this topic that can be covered, such as how to strategically move the point of reference in Lean across each layer of a team, or bring it inside the upper layers of the development team. I have used this approach previously during my time at Turner to Value Stream Map one of our development/deployment processes, ‘Release0' (some teams pre-deploy a skeleton/template to Production prior to Sprint 1’s Development). Applications of these mindsets I’ve discussed here are very intriguing to me, and you start to see the potential waste in every process. As you become more of an expert on Lean and Agile relativity — that is, how you approach and apply the principles relative to a given process or problem — the more you will leverage each appropriately. Don’t forget, part of CI is to learn and grow — there are others that know much more than me and I hope to learn from them and incorporate their teachings and feedback to continue to provide value.

If software development was like alchemy, choosing the right ratios of methodology is like potion-making.

The analogy of brewing the right potion depends on the ratios you put into the cauldron. Factors such as requirements, timeframe, culture, and team are the ingredients weighed.

Lean’s focus on simplicity and waste reduction makes Agile more efficient, but takes time away from it’s deliverable, at least upon first glance. Agile gives you a fixed process you can tweak and then lift-and-shift in a very short amount of time, and it’s repeatable. That makes it easy to clump the ideas of Lean into Agile, but they are different, albeit similar. The downfall of just embracing Agile is that it could be met with process-related roadblocks that go and remain undetected — constants across each layer of the process that hinders efficiency — and no one is the wiser. A team could be delivering perceived value in a wasteful way, even with what may seem like valid feedback.

Ultimately the decision is yours over which mixture goes in, so to speak. It could be (Agile-Lean) a 60–40, or a 20–80 depending on what and how you weigh. I am of the belief that custom mixing a solution to what works based on evaluation of your weights and doing it layer-by-layer as a tailored approach is much more successful and meaningful than something like SAFe, or any other Lean-Agile approach that comes pre-packaged. Oftentimes it is the CTOs, Directors, or other C-suite executives that get swept up in the marketing of such consulting services or products, thinking it’s the ambrosia of enterprise productivity. And it may work for that use-case, and it’s a viable solution after evaluation. Nothing is wrong with delivering value, as it is the point. But remember; flexibility, quality, high standards, investment in people and diversity are all more important than forcing the workforce underneath to die by the ‘Lean/Agile’ sword. Each of those must be unpacked to their fullest, or else you will lose talent, trust, and create tension. You haven’t made a potion, you’ve made poison.

Now that you have the tools and we’ve delved into the esoterica of software development alchemy, you’re definitely in better shape to begin your wizardry.

Potions in hand — embark on your quest of innovation and delivering value using both of these tools in the ever-evolving professsional landscape.

Good luck and have fun!
Thanks for reading,

-Kevin

--

--