While they do have their differences, lean methodology vs agile also have their similarities. And ultimately, though they’re often framed as “lean versus agile” – even in this blog post! – it’s not an either/or choice. These methodologies are complementary and can be layered on top of each other.

You can adopt both, and you probably should.

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. It forces you to measure what you’re doing, then learn from it and iterate as you go.

Lean 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 in product development?

Agile is an approach to project management that allows 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 comes 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. 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. 

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 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! Lean is very much around this idea of pivoting.

If you’re trying 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.

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 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.

Final word

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.

The post Lean Methodology vs Agile in Product Management appeared first on ProdPad.