Why I Prefer Lean

Lean isn't alluring or glamorous. It won't give you a certification to put on LinkedIn. There is no Lean Master role to pad your resume with. It's just a collection of principles that came from Toyota figuring out how to build cars efficiently in post-war Japan with limited resources.

And somehow, those principles work better for software than frameworks designed specifically for software.

The irony isn't lost on me.

It Starts With Waste

Lean's core insight is almost offensively simple: identify waste, eliminate it. That's it. No ceremonies, no mandatory meetings, no poker planning. Just a relentless focus on what adds value and what doesn't.

The original Toyota Production System identified seven types of waste (later eight, because someone couldn't resist adding one more). In software:

Waiting: Code sitting in review for three days
Overproduction: Features nobody asked for
Extra processing: Estimation meetings that estimate estimates
Transportation: Knowledge that has to be re-explained six times
Inventory: Half-finished work rotting in branches
Motion: Context switching between seventeen priorities
Defects: Bugs that make it to production
Unused talent: Smart people in pointless meetings

Look at your last sprint. How much of it was actually building software? Lean says everything else is waste. Not necessary overhead. Waste.

Pull, Don't Push

Here is where Lean gets interesting. Instead of planning everything upfront and pushing work through a pipeline, you pull work when you have capacity.

I led a team 1.5 years ago and decided switching from two-week sprints to continuous flow with WIP limits. We agreed on trying it. Deployments went from every two weeks to daily. Cycle time dropped from 12 days to 3. Lead time from 18 days to 5.

No story points. No velocity tracking. No sprint planning. Just "we can take two more items" and "this one's done, next."

The data is boring but consistent: pull systems with WIP limits outperform push systems on cycle time, quality, and predictability. Don Reinertsen documented this in The Principles of Product Development Flow. Mary and Tom Poppendieck wrote an entire book (Lean Software Development) translating Toyota's principles to code.

But most teams never try it because Scrum is the default, and Lean sounds like extra work.

Decide as Late as Responsibly Possible

This is my favorite Lean principle because it's so counterintuitive.

Traditional planning says: decide everything upfront, then execute. Lean says: defer decisions until you have the most information. Build the smallest thing that lets you learn, then decide what's next based on actual data.

Not "fail to plan." Not "wing it." Decide late means deciding well.

I've seen this play out repeatedly. Team A spends three weeks speccing a feature, builds it in two weeks, then discovers users want something different. Five weeks, wrong solution.

Team B builds a prototype in three days, puts it in front of users, learns what actually matters, then builds that in a week. Ten days, right solution.

The difference isn't talent. It's when you make irrevocable decisions.

Amplify Learning

Lean treats every line of code as an experiment. You're not building to spec. You're building to learn.

This means:

Small batches (deploy often)
Fast feedback (measure real usage)
Tight loops (integrate, test, deploy continuously)

The evidence here is overwhelming. The 2023 DORA State of DevOps report shows that elite performers deploy on-demand (multiple times per day), have change failure rates under 5%, and restore service in under an hour. Low performers deploy monthly, fail 46-60% of the time, and take weeks to recover.

The difference? Elite performers treat software development as a learning process with fast feedback loops. Low performers treat it as a requirements fulfillment process with long feedback loops.

Lean optimizes for learning speed. Everything else optimizes for process compliance.

The Uncomfortable Parts

Lean isn't perfect. It requires discipline that frameworks enforce externally. No mandated standups means you have to actually communicate. No sprint boundaries means you have to actually finish things. No story points means you have to trust the team.

It's harder to audit. Harder to "scale." Harder to sell to executives who want Gantt charts and burn-down reports.

And it absolutely fails when:

The team doesn't trust each other
Management demands predictability over learning
There's no way to get fast user feedback
People want to be told exactly what to do

Lean assumes you're optimizing for outcomes, not activity. If your organization measures hours logged and story points completed, Lean will look like chaos.

Why It Works for Me

I've shipped more software, faster, with fewer defects using Lean principles than I ever did with structured frameworks. Not because I'm particularly clever, but because Lean aligns incentives correctly.

Every meeting is questioned: does this add value or is it waste?
Every process is measured: does this speed up learning or slow it down?
Every decision is deferred: do we know enough yet or should we build something small and find out?

The result isn't anarchy. It's intentional simplicity. We have processes, just not ceremonies. We have planning, just not upfront over-planning. We have structure, just not scaffolding.

The Evidence Pile

If you want citations:

Womack & Jones, Lean Thinking (1996) - the foundation
Poppendieck & Poppendieck, Lean Software Development (2003) - the translation
Reinertsen, The Principles of Product Development Flow (2009) - the math
Kim et al., The Phoenix Project (2013) - the narrative
Forsgren et al., Accelerate (2018) - the data

The research consistently shows: small batches, fast feedback, continuous delivery, and low WIP beat every other approach on speed, quality, and sustainability.

Lean isn't magic. It's just aligned with how learning actually works.

I use Lean because shipping beats planning. The evidence agrees, but you're welcome to run your own experiments.