Difference between Agile and Lean
What is the difference between Agile and Lean?
A lot of people are asking about the difference between Agile and Lean. Are they the same? Which came first? Which is better? Better for what? That depends a lot on your context. You also need to understand the background and purpose of each approach. This article attempts to answer all of these questions.
The quick summary of what is the difference between agile and Lean is:
- Lean is an older system, created in a manufacturing context
- It has a focus on improving flow and reducing waste
- Lean inspired a lot of the ideas in the agile software development movement
- Agile is more focused on discover and innovation, and is more suited to software contexts.
Let’s now go into more detail on these points. So we can understand the agile vs Lean debate.
Lean came first. It is Japanese and old
Lean is old – very old. “Lean” generally refers to a body of knowledge called more specifically “Lean Manufacturing”, which was developed in Japan in the 1950s and 1960s by an engineer named Taiichi Ohno.
Taiichi Ohno is thought of as the father of Lean Manufacturing
D Edwards Deming helped influence Lean.
He called it the Toyota Production System. He got many of the ideas from an American management thinker called William Edwards Deming (see picture).
Lean Manufacturing turned a lot of traditional concepts on their head:
- Production should be based on pull (demand), not push (supply). You make something when someone orders it, rather than first making things then hoping somebody orders them.
- This is related to the idea of Lean Just-In-Time Production (JIT), where things are made just as soon as they are needed.
- Production is most efficient when done in small batch sizes (as small as possible), rather than large batches to exploit economies of scale
- Taking your time to focus on quality, above all else, increases rather than decreases output and efficiency
- Workers, not managers, are responsible for defining the way they work
- Rather than carry out predefined tasks over and over again, workers must continuously improve the way they work (kaizen).
These Lean principles were heretical to modern American management theory. But the Japanese industrial companies adopting these ideas quickly outperformed their American counterparts.
Agile is more based on development rather than manufacturing
The agile methodology or approach is a set of ideas around software development. It came about in the late 1990s as people tried to find better ways of making software.
Lean came from manufacturing contexts
Lean has its roots in industrial manufacturing, but many of its ideas are quite general and can be applied to lots of disciplines. Agile project management (or agile product development) is more specific to software development and doesn’t have many ideas that are applicable outside that field (depending on what flavour of Agile development process you’re talking about).
Agile and Lean have some similarities
There are some clear similarities between Agile principles and Lean. Two that quickly come to mind are Small Batch Size and Inspect and Adapt. Lean Manufacturing prescribes building things in as small batches as possible. Rather than making 100 widgets at a time, make them one at a time. It (counter-intuitively) is more efficient that way.
DevOps is inspired by some of the Lean ideas, such as optimizing for flow of value
Agile practices (especially when following DevOps principles such as Continuous Delivery) prescribes many frequent small releases of software, rather than infrequent large releases. Lean Manufacturing also tells us that any process should be continuously inspected and adapted so as to improve it. Agile (more specifically, the Scrum framework) tells us we should hold regularly inspect our outputs (at a sprint review) and our ways of working (at a sprint retro) to find ways to improve them.
But Agile and Lean are actually different
Tom and Mary Poppendieck describe the fundamental differences between the two as being that Agile is about optimising a development process, while Lean is about optimising a manufacturing process. This means that Agile is about building one new thing for the first (and only) time. While Lean is about building the one same thing over and over again.
In manufacturing, variation and rework are bad, while in product development, they are good.
When building something for the first time, you want to continuously iterate. To keep going back and revisiting your design, changing it where necessary based on new information or feedback. In manufacturing, you generally have a predefined product. Then you want to produce as many high-quality instances of that thing as you can, as cheaply as you can.
Lean is about process and quality, Agile is about scope and value
If you read the lean literature, there is a big focus on process improvement (via things like value stream mapping) and quality (zero defects is the goal). While in Agile iterations, the focus is more around scope (how do we define and manage scope for a new software product) and value discovery (how can we rapidly produce something and learn from it via customer feedback).
An agile product owner and an agile backlog play a crucial role in this value discovery and identification. Agile sprint planning is an example of how agile teams can quickly plan and pivot in small steps, to enable this rapid discovery and innovation.
Each has their strengths. I would recommend anyone interested in either one should know at least something about the other.
Value Stream Mapping
You may have heard of Lean value streams, or value stream mapping. This idea (sometimes shortened to VSM) is one of the strong ideas of Lean continuous improvement that has filtered through to other areas like agile.
Value stream mapping is an important part of Lean
In Lean, you want to map the entire “value stream”, from the producer of a product or service, to the consumer. The idea is to identify all the activities required to get value to the customer. And then look at which ones really add value, and which ones don’t. And how long each one takes, so you can reduce waste and improve the overall lead time and cycle time. Lean cycle time is a very important metric for understanding how quickly you are working and delivering value.
Lean Six Sigma
Lean Six Sigma is a famous framework that is inspired by Lean. I won’t go into too much detail here, but LSS (Lean Six Sigma) is intended to apply Lean thinking to any repeatable process or system. It has a ruthless focus on quality and efficiency.
I don’t have direct experience in or working around Lean Six Sigma, so I won’t go into much detail. You will find a lot of different stories and opinions on Lean Six Sigma. Including some places like 3M that did a big move into LSS, and then abandoned it.
So it is certainly controversial. If you have some experience or thoughts on LSS, please share them in the comments below.
What about this whole “Lean Startup” thing?
Good question! Eric Ries’ 2011 book “The Lean Startup” proposed a new model for businesses. Basically, you around quickly produce a Minimum Viable Product, gather validated learning from it. Then you make a quick decision to “pivot or persevere” based on that learning.
Eric Ries’ influential book, “The Lean Startup”
While inspired by the Japanese Lean idea of reducing waste, it is not really traditional Lean at all. In fact is has more in common with Agile. It has spawned a series of books with titles like “Lean UX” and “Lean Enterprise” (both of which are very good), and these will probably add to the confusion.
What about this whole “Kanban” thing?
That’s a very good question. Kanban has become very popular lately in the software world and the agile community in particular.
Let’s first define and separate two uses of the term, though. The original term “kanban” referred to a pull-based system of work allocation and demand signalling, and was part of Lean.
David Anderson’s “Kanban blue book” was a landmark in the Lean / Agile field
It had been around in the Japanese manufacturing world (i.e. Lean efficiency) for a long time and just stayed there and nobody outside of those circles knew of it.
But then in 2010, David J. Anderson wrote the book “Kanban: Successful Evolutionary Change for your Technology Business”. It was based on his knowledge of the original Japanese Kanban system, plus experience he had had implementing some of those ideas while working at Microsoft. And maybe some other places.
The book went on to become very influential, and a lot of people in the software development world (especially the agile end of things) bought into these Kanban principles.
So while Kanban is not the same as Lean per se, it shares some common ancestry. And has a few similar ideas.
Kanban is based around “evolutionary change” – so it begins where you are. (As opposed to say the Scrum framework, which begins by introducing new roles, artifacts and events). It focuses on visualising and then improving the flow of work within a system. So Lean waste reduction shares some ideas but is more focused on repeating and improving a standard process.
Contrary to popular belief, there is nothing saying you can’t implement some Kanban ideas within an agile framework or agile software development system, such as Scrum! In fact, many agile teams or Scrum teams do apply some or all of the ideas in Kanban. Agile or Lean teams doing Scrum should definitely consider this. Since you could end up with the best of both worlds!
Summary
So hopefully by now you have an understanding of the difference between agile and lean. Agile is more focused on discovery and innovation and iterating, while Lean is more based around flow, efficiency and removing waste.
If you’re still unsure about the difference between Agile and Lean, this video might help clear things up.
