Lean vs Agile: What’s the Difference (and Similarity)

Everyone’s been crazy about Agile for nearly a decade and not without a reason. Lean, Agile’s grandpa, is reclaiming its positions nowadays too. In this article, we’ll compare the two and find out which one suits your project needs better.

What is Lean Methodology?

Before we start comparing Agile and Lean, let’s freshen up our memories a little bit. What’s Lean, what’s Agile and how do they work?

Let’s start from Lean as it appeared first. 

To understand how it works, we need to learn how Lean came into being.

Although the history of Lean Manufacturing starts as early as 1913, with the first moving assembly line at the Ford’s plant, it blossomed in the midst of the post-war period in Japan, not the US.

WW2 hit Japan badly. It put innovation on a hiatus and for the decades to come Japan was to become a laggard in the world economy. The Japanese had a huge hole in the budget and no prospects for the future. To everyone's surprise, with a wize government policy and financial aid from the US to Asia, Japan started their glorious rise from the ashes. What is today known as Japanese economic miracle occurred.

For Toyota - the cradle of Lean Production - the post-war reconstruction period brought new partnership opportunities. In 1950 Toyota representatives visited the Rouge plant of Ford in Dearborn, Michigan, which at that time was the greatest Ford’s plant. The mission of the visit was to learn the Ford principles of work and adopt them in the Toyota production. Toyota did learn something, but it wasn’t how to build Toyota according to the US rules. On the contrary, they understood that Ford's massive production style couldn’t be used on their much smaller plants which above all produced customized cars in limited batches. Thus Toyota took what it needed from Ford and adjusted it accordingly.

Toyota adopted tech-savvy Ford’s methods, but in addition to that it carefully studied the market to give it what it needed and to the extent it needed it. The philosophy of Toyota's Lean Production was based on resource scarcity, precision and economy. Toyota followed the "automation with a human touch" principle and relied heavily on its employees' talent rather than the power of tooling alone. At the same time, Toyota incorporated some specific attributes of Ford’s massive production style, which allowed it to grow far beyond the Japanese market.

In such a way, a new great methodology was born (find more of Lean history here). Later on it was adopted by many other industries that were absolutely unrelated to the automotive industry, such as Software Development, for example.

To be exact it was Tom and Mary Poppendieck, the authors of a best-seller Lean Software Development: An Agile Toolkit, who introduced Lean Software Development principles. Here they are:

It is how the software industry tailored Toyota’s "what is needed, when it is needed, and in the amount needed" to their needs. It has just a little left of the original Lean methodology, though the core statements remain:

• Give the customer a product of the highest quality possible
• Find the way to do it in the most efficient way 
• Trust your people, rely on their talent and empower them to help you do the 2 above things.

Now it’s time to switch to our second methodology of interest - Agile.

What is Agile?

In time, rigid Lean methodology became kind of a burden for the tech world. 

Technologies were growing in power by leaps and bounds, with deadlines becoming shorter and the cost of delay - higher. Many paid the highest cost of delay when their software died because no one no longer wanted it…

To make things clearer, let’s have an example. Imagine a case where a group of users needs a product right here right now. Something like an e-shop app. But instead of here and now they receive a perfectly made software ...in a year. Yeah, that was often the case, as flawless software takes quite a time to develop. But no one wants it anymore in a year! The e-shop may be long dead, so the software goes to the software graveyard too. 

That was the problem of the software industry of the previous century that Agile was supposed to deal with. 

So, how did it appear? Who made it up? The solution appeared somewhat by itself...

The 90’s of the previous century saw the emergence of a great number of new methodologies. Those were the methodologies promoting quick prototyping phase with incremental product improvements. 

No one wanted rigorous planning and counting every penny anymore. Getting a viable product - a confirmation that the idea works - was now important. 

A funny fact is that the Agile Manifesto did not exist yet. But even despite the fact that there was no term for this new movement, it kept growing. Those new development approaches appeared in a wild and uncontrollable manner indicating some strong urge for a change growing deep inside the software industry. 

Thus, the year 2000 came and brought some good news for those craving for the changes.

In 2000, 17 very important software developers of that time (including Martin Fowler, Jim Highsmith, Jon Kern, Jeff Sutherland, Ken Schwaber, and Bobert C. Martin) met in Oregon. They have finally set to discuss a) how to deliver great features to the users just in time; b) how to solve the product-market fit problem and close the software graveyard once and for all; c) how to receive the feedback on the usefulness/uselessness of the product ASAP. Agile wasn’t born that day, but at least it was conceived.

In a year the same 17 developers met again. This time at a ski resort in Snowbird, Utah. They were seriously planning to finish what they started a year ago and finally come up with Agile Manifesto:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan.

These 4 key values of Agile sound so simple (even naive to some extent), but those 4 lines would determine the course of software development since then.

By the way, if you’d like to find more about how Agile started its glorious journey, I highly recommend reading Clean Agile: Back to Basics by Robert C. Martin. Learn the story of Agile firsthand told by one of its founders. 

So, what is Agile? It’s a family of methodologies that are designed to enable fast delivery of the product to the user. Agile approach allows to get a quick YES or NO from the user, the feedback that says whether a product should grow further or be banished from the market; what features are good or bad, etc. In Lean, where every minute counts and resources are too precious to experiment, developing an MVP only to find out that the idea is a crap, is a luxury no one can afford. Yet, it’s the risk that Agile advocates agree to take.

Seems like we’ve already started comparing them.So, we’d better move to the next paragraph specifically dedicated to the methodologies differences. 

Agile vs Lean - the difference

Now as you know the story behind the advent of each methodology you’re equipped with the right tooling to compare them.

Risk

Agile is very risk-friendly: risk is an opportunity. 

Despite the fact that short iterations help minimize risks in Agile projects, we’re assuming that we can easily lose those 2-3 weeks that an iteration lasts. Agile implies business analysis, risks minimization strategy and staff, but in essence it was created to enable fast development. Fast, not 100% accurate. That’s the spirit! 

On the contrary, Lean is risk-averse.

No matter how many years have passed since its inception, it is the post-war Japan that dictates how Lean is applied. Rigid, analysis-based, focus on economy. It’s a nice option in cases where the risk of delay is lower than the risk of delivering a poor quality product.

Waste

There’s no such thing as waste in Agile. 

Say, your team of analysts says that Feature A will be the market hit. In case it doesn’t end up that way we introduce changes and move forward. No one laments over wasted money and resources. They simply don’t have time for that as time is the most precious resource in Agile. Agile does welcome any cost minimization, but only time is an irreplaceable resource.

Fail fast and start again!

In the case of Lean, a feature that no one wants is a waste, and you mustn’t produce waste. A Lean team carries out a study beforehand and is setting up with a new feature only with the feasibility study results on hand. The study may cost a team a few extra hundred dollars, but it’s far less than an unwanted feature would cost to build.

Change

Agile teams change their course on demand. What can be the driver for a change? A new vision of a product owner, a change in market conditions, anything. If the potential benefit of a change outweighs the potential risks, we’re in.

Lean is a change averse methodology. As every decision is backed by the feasibility study results, the team cannot change its course. If a change occurs, the team has to process it and change the plan. It can be labor intensive.

On the other hand, on the way to perfection - and Lean highly values perfection - changes are favoured, but those shouldn’t be spontaneous instantaneous alterations (which is often the Agile case) 

Cost of poor quality vs cost of delay

Well, that’s actually the essence of the Agile vs Lean battle. 

Lean’s intention is to reduce cost by any reasonable means. Agile’s - to reduce time2market.

At the same time Lean teams don’t wait years to deliver the product that no one needs. Agile doesn’t imply building crappy software either.

The thing is, the two methodologies are not in conflict, they simply have slightly different priorities. Lean prioritizes quality over time, while Agile - time over quality. Where the balance lies - it depends in each particular case.

Lean vs Agile - two of a kind

The two methodologies have too many things in common not to see the truth - they are two of a kind. 

Hence, let’s list those similarities for clearance. 

Value

Both Agile and Lean were designed to bring value for the customer, but each in its own way. Lean - through perfection and cost reduction, Agile - through fast delivery, early market entry and monetization. It doesn’t mean that they are competitive, rather - they are complimentary.

Empowering talents

People pay utmost importance in each case. 

Toyota empowered its employees back then when it wasn’t mainstream. It put the talent’s genius over the effectiveness of a machine. 

Agile? It was primarily about people. Check out the first line of the Agile Manifesto, if you have your doubts.

Small input - big impact

Both methodologies prefer starting small over ambitious beginning. 

Moreover, small batches in Toyota’s case and short iterations in Agile serve for the same purpose - risk mitigation.

Flow

Flow is super important in Lean where each step should add its specific value. 

In Agile, flow is equally valuable. Req’s - Design - Develop - Test - Deploy - Feedback is Agile teams mantra.

Cost saving

Both methodologies are savings-oriented, but each in its own specific way. 

Lean - through cost reduction during development, Agile - though quick market entry and fast monetization.

ROI

Lean teams conquer the markets by developing one of the class products of outstanding quality.

Agile’s target is perfect timing.

In both cases methodologies guarantee high ROI although business objectives are different.

Tool. Just a tool

That’s the greatest similarity of these two methodologies. And there’s so much misconception about it.

Methodology is just a tool. It works when you apply it right and, what’s most important, it has one application area - processes. It’s neither a silver bullet, nor a Swiss army knife. It won’t give your talents some extra knowledge they lack. Neither will it increase commitment. 

Lean was supposed to make the production cost-effective, make the whole factory work as a well-oiled machine; Agile was designed to reduce time2market and get feedback quicker. 

Bottomline

Last but not least. 

Too often clients approach us with an illusion that some methodology may help them beat their competitors. To make things worse, they often misinterpret the methodology of their choice. The most common misconception is that Agile allows cutting costs and creating a perfect  product in no time. It’s such a lie, and some unknown genius has long ago found the answer to such queries (see below).

Lean is cost-efficient, analysis-backed and wasteless. It’s perfect for the industries where cost of delay isn’t critical (automotive, for instance).

Agile’s objective is to hit the market first, test the idea and make money from it. Thus we solve the problem of the software graveyard - we offer the products before the customers are gone and there’s high demand for it.

In short, Lean is about saving more, while Agile is about earning more.

Some Agile advocates would even claim that the Agile methodology was created to improve Lean, not to substitute it.

Combining them may seem a perfect idea, yet keeping those two balanced is a tough job. Nevertheless, you can give it a try. Keep watching how you’re doing. If you’re lagging behind your competitors, try adding Agile elements. If your expenditures have recently skyrocketed - why not give Lean a go? 

P.S.

Businesses appear to make money, not to be Agile (or Lean)

After all, do remember t0 make some money as this is what business is about. 

Regardless of your methodology of choice, if your employees are happy and the market is favorable, you’ll win, hands down. 

And don’t you worry about that Agile thing or Lean or whatever they say. Your greatest weapon is always your people.