Lean Methodology vs Agile in Product Management

Lean and agile got you in a spin? As two complementary methodologies, it’s actually more common than you might think to get the two confused. That’s why we’ve written this article to cover everything that you need to know to understand where the similarities are and when it becomes “lean versus agile”.

Now, this whole thing can get pretty murky pretty quickly so I need you to trust me and be open to the fact that, even though lean and agile have key differences as project management methodologies, they do not have to be an either/or choice.

You might actually want to do a mix of them both, and after this article, you will know exactly how to do that.

In this article, we will cover:

• What is lean methodology?
• What is agile methodology?
• Lean methodology vs. agile
• Can you be agile and not lean?
• Can you be lean but not agile?
• How to get the entire organization to embrace agile and lean practices

What is lean methodology?

Lean methodology is about building continuous discovery and validation into your product development, so you don’t waste any resources doing the wrong thing along the way. At it’s core lean principles force you to do continuous improvement by measuring what you’re doing, learning from it, and iterating as you go.

Lean thinking really shines when you don’t know what you’re building. You don’t know what the final product is; you’re building into uncharted territory. No one can say what the finished product would look like exactly because there’s no blueprint to follow. (If you do already know what it looks like, then you’re probably getting ahead of yourself and you’re not working in a lean way. Lean is that discovery.)

What is agile methodology?

Agile is an approach to project management that allows agile teams to work fast and nimbly, to put pieces of work together in the right order, estimate how long a project will take, and have a clear idea of what the end product might look like. If you’re building something that’s prefabricated, using a template, or simply following orders and filling requests, then agile principles come into play. There are different methodologies within agile development. Some teams prefer Kanban style while others prefer Scrum, a more traditional sprint way of working.

There is no right or wrong answer here. for which approach to development you take, to be honest, it depends on your team and what it is you’re doing. If you’re curious how this might fit with your team, check out these ways to introduce agile product development.

Lean Methodology vs Agile

Let’s get into a couple of the differences between the two. Not everyone will agree with me on these, but hear me out!

How they go hand-in-hand

You can’t be lean unless you’re already agile, in my opinion. Lean requires you to have the ability to test the riskiest thing first to check assumptions early and often. And agile enables the iteration part of lean.

So lean is a particular mindset that is layered over an agile way of working.

Both, at their core, are about learning and iterating, but both can be taken out of context and done badly by teams. 

 I was lucky enough to have Jeff join me for a fireside chat, it’s well worth a listen to if you want to hear about lean teams and iterative approaches to software development. 

Can you be agile and not lean?

Yes, you can be agile and not lean. I’ve seen companies work in agile ways, through sprints and fast releases. But they just build and build and build, without taking the time to measure what they did and then learn from it – which, of course, is the whole lean development cycle.

They take a big project, cut it up into pieces, start at the beginning and build all the way through. Sprint by sprint, they don’t stop to check that what they’re building is valuable. Which means they don’t have the opportunity to pivot! The lean approach is very much around this idea of pivoting.

If your primary goal is to swim out to an island, you won’t keep your head down the whole time, you’ll stop to check if you’re still on course. That way you don’t spend too long swimming in the wrong direction.

The key thing is to have stopping points after deliveries to make sure that’s actually the right thing. This continuous delivery within software development teams needs process improvement because you can’t deliver technical excellence in a continuous flow without that way of lean thinking.

Can you be lean but not agile?

Not really, because lean requires you to test the riskiest thing first, to check assumptions early and often.

If you’re doing your discovery work upfront but not breaking down the project into smaller pieces (i.e. you aren’t taking on an agile methodology), then you’re sort of running straight into a big waterfall project management situation and not coming up for air. And then you’re again missing the opportunity to pivot, which simply isn’t a lean way of working.

This is why I believe that lean methodology requires agile in the first place.

Do all this before code development

One of the things I think a lot of people miss in the lean methodology vs. agile “debate” is that you shouldn’t necessarily just be agile in your code development. Code is the most expensive part of product development. The goal is to minimize as much code development as possible and to de-risk a project as much as possible before coding begins.

Creating Minimum Viable Products and testing the riskiest stuff first is a great, lean way to approach your work – which you can then execute in an agile way. As a project/ or product manager incorporating lean and agile core principles into every part of the process means that you can eliminate waste.

How to get the entire organization to embrace agile and lean practices

Find the flavor of agile that works for you – whether that is Kanban or Scrum or Scrumban or any one of the other different variations. At ProdPad, we basically have a customized version of Scrumban, because we’ve adapted so many different pieces to fit our particular team. And it’s really effective!

Find the process that allows you to:

• Break down work and deliver it in small chunks
• Have short spans between deliveries and releases
• Share work with the rest of the team so that you can do retros and reviews
• Incorporate those learnings into the next move.

And last but not least, think about how you’re actually going to measure what you have, how to set target outcomes and measure actual outcomes. Decide how you compare these things, and  how you’ll use what you learn from these comparisons. It’s not just about running retros, but it’s about reacting to what you learn in the retros.