The Guide You Need to Switch from Scrum to Lean

Let me describe a company. Not fictional. Composite, maybe, but real.

Six full-stack teams, 2-7 people each, each owning a product. One ML team everyone fights over. One UX team with a six-week backlog. One QA team of four people testing for forty developers. Requirements live in Slack threads, PowerPoint decks, Word docs, meeting notes, and the collective memory of whoever was in that call three weeks ago.

Every morning at 9:30, each team gathers for standup. "What did you do yesterday?" "What are you doing today?" "Any blockers?" Fifteen minutes of reporting status nobody remembers by 10am. Then everyone goes back to work, or more accurately, back to asking other teams when their thing will be ready.

They call this Scrum. They call this agile.

And you know what? They're not wrong to. They're doing exactly what most companies do: adopting the ceremonies while missing the philosophy, claiming flexibility while drowning in coordination overhead, insisting they're agile while waiting three weeks for the ML team to look at their request.

This isn't incompetence. This is what happens when good people with good intentions grow a company without realizing that the informal systems that worked at 15 people catastrophically fail at 50.

Let's fix it. Not by shaming anyone, not by declaring Scrum evil, but by acknowledging reality and building something that actually works.

Step 0: Acknowledge What You Actually Have

Before you can transition to Lean, you need to admit what you're transitioning from. And it's not Scrum.

Scrum has product backlogs, sprint planning, reviews, retrospectives. You have Slack messages and prayer-circle standups. Scrum has a definition of done. You have "done when QA gets to it, maybe next week."

You have something more common and more honest: organized chaos with a standup habit.

The standup isn't useless. It's a daily reminder that other humans exist and are also confused. That's valuable. It's just not a methodology.

What you actually have:

Tribal knowledge: Critical information lives in people's heads
Request-driven development: Work appears via DM, meeting mention, or hallway ambush
Dependency hell: Every team needs something from every shared service
Invisible queues: Work piles up in Slack threads and "when you get a chance" requests
Status theater: Standups where everyone reports but nobody knows what matters

This isn't a Scrum problem. This is a "we grew too fast and our systems didn't scale" problem.

Lean can help. But only if you're willing to make things visible that are currently comfortable to ignore.

Phase 1: Make the Invisible Visible

You can't eliminate waste until you can see it. Right now, your waste is hidden in Slack scroll-back and "just ping me" culture.

Start With One Team

Pick your most functional team. Not your most chaotic (you'll need wins first) and not your most skeptical (you'll need buy-in). Pick the team that's frustrated but willing to try something different.

Create a Physical or Digital Board

Yes, a Kanban board. Three columns to start:

To Do
In Progress
Done

Radical simplicity. Every piece of work goes on a card. Bug report in Slack? Card. Feature request from sales? Card. "Can you just quickly..." from the CEO? Card.

Everything visible. Everything tracked. No exceptions.

The goal isn't perfection. The goal is seeing your actual workload instead of pretending you're on top of it.

Set WIP Limits

Here's where it gets interesting. Your "In Progress" column gets a limit. For a 5-person team, start with 5 items max. One per person.

Not because people can't multitask. Because multitasking is where work goes to die.

When you hit the limit, you can't start new work. You have to finish something. Or you have to explicitly decide that the blocked item is less important than the new thing, and move it back.

This will feel wrong. You'll want to make exceptions. Don't. The discomfort is the point. It reveals your actual constraints.

Track Cycle Time

For every card, write the date it moved to "In Progress" and the date it hit "Done." At the end of two weeks, calculate average cycle time.

That number is your baseline. It's probably worse than you think. That's fine. You can't improve what you don't measure.

Phase 2: Expose the Dependency Tax

Now that work is visible, the next revelation awaits: how much time you spend waiting for other people.

Add a "Blocked" Column

Between "In Progress" and "Done," add "Blocked - Waiting."

When someone needs the ML team, it goes here. When QA is swamped, it goes here. When UX hasn't looked at your mockup request from two weeks ago, it goes here.

The blocked column will terrify you. It will be the fullest column on your board.

Good.

Tag Dependencies

Every card that involves another team gets tagged: [ML], [UX], [QA]. Track how long items spend blocked on each dependency.

After two weeks, you'll have data:

Average time blocked waiting for ML: 8 days
Average time blocked waiting for QA: 5 days
Average time blocked waiting for UX: 12 days

Your cycle time isn't 3 days of development. It's 3 days of development plus 25 days of waiting.

This is the dependency tax. The hidden cost of shared services and "just ping them" culture.

Calculate the Cost

If your average cycle time is 28 days but only 3 days is actual work, you're operating at roughly 11% efficiency. The other 89% is coordination overhead.

Lean doesn't say "stop collaborating." Lean says "make the cost of collaboration explicit, then optimize it."

Phase 3: Kill the Invisible Queue

The ML team isn't lazy. They're underwater. The QA team isn't blocking you on purpose. They have 47 things in their invisible queue.

Shared services without visible queues create a tragedy of the commons. Everyone's request feels urgent to them. Nobody sees the collective burden.

Make Service Queues Visible

Each shared service team gets their own board. Public. Everyone can see it.

ML team's queue:

23 items waiting
4 items in progress
Average wait time: 9 days

QA team's queue:

31 items waiting
4 items in progress
Average wait time: 6 days

Suddenly, the mystery disappears. You're not wondering why your request is taking forever. You can see 22 items ahead of you.

This does two things:

Teams stop assuming shared services are idle
Shared services stop drowning in invisible guilt

Implement Pull for Shared Services

Here's the key change: shared services don't get "assigned" work anymore. They pull from their queue when they have capacity.

This means:

No more "just a quick favor" that bypasses the queue
No more executive requests that jump the line (or if they do, it's explicit)
No more DMs that become commitments nobody tracked

Everything goes in the queue. Everything is prioritized. Everything is visible.

Will people hate this? Initially, yes. Because it makes them confront that their "urgent" request isn't more urgent than everyone else's urgent request.

But after two weeks, something magical happens: people stop creating urgent requests. They plan ahead because they can see the lead time.

Phase 4: Optimize Flow, Not Utilization

The deadly trap of shared services is optimizing for utilization. "We need to keep the ML team at 100% capacity!"

You don't. You need to keep work flowing.

Introduce Slack Time

The ML team needs buffer capacity. Not because they're slacking. Because variability in request complexity means 100% utilization guarantees queue explosion.

Queueing theory (specifically, Kingman's formula) shows that as utilization approaches 100%, wait time approaches infinity. At 90% utilization with variable work, average wait time can be 10x the service time.

So give them slack. 20-30% buffer capacity. Time for:

Unplanned urgent work (real urgent, not fake urgent)
Learning and improving tools
Proactive work that prevents future requests
Actually thinking about problems instead of ticket-grinding

Swarm on Blockers

When something is blocked, don't just mark it and move on. Swarm it.

If a feature is blocked on ML, can someone from the product team pair with ML to unblock it? If it's blocked on QA, can the developer write automated tests to reduce QA burden?

Lean thinking: optimize for flow, not for perfect specialization. Sometimes "wasting" a senior developer's time helping QA is faster than waiting three days for QA to get to it.

Phase 5: Replace Status Theater with Actual Information

Remember those daily standups? The ones where everyone says what they're doing but nobody knows what actually matters?

Try This Instead

Stand in front of the board. Look at the rightmost items first (closest to done). Ask:

"What's stopping this from being done today?"
"Who needs to be involved?"
"What's the risk if we slip?"

Then look at blocked items:

"How long has this been blocked?"
"What can we do to unblock it?"
"Is it still worth doing?"

Then, and only then, look at what's starting:

"Do we have capacity?"
"Is this the most important thing we could work on?"
"What might block this?"

This takes 10 minutes instead of 15. But you leave with decisions, not status reports.

The board already shows status. The standup is for solving problems.

Phase 6: From Invisible Chaos to Transparent Chaos

After three months, your board will look terrifying. So much visible work. So many dependencies. So much waiting.

This is progress.

You haven't created chaos. You've made existing chaos visible. And visible chaos can be fixed.

What you'll discover:

40% of requests can be self-served with better tools/docs
30% of requests shouldn't exist (unclear value)
20% of requests could be batched (ML team does analysis every Tuesday instead of on-demand)
10% of requests are actually urgent and important

Start Cutting

Look at your "To Do" column. For every item, ask:

What happens if we don't do this?
Can the requestor do this themselves with different tools?
Is this solving the actual problem or treating a symptom?

Kill 30% of your backlog. Just delete it. If it was really important, it'll come back. And if it comes back, you'll have data about why it keeps coming back, which means you can solve the root cause.

This will feel dangerous. Do it anyway. Overcrowded queues slow down everything, including the important work.

Phase 7: Continuous Deployment Over Continuous Planning (Week 13-16)

By now, you have visible work, managed dependencies, and optimized flow. Time to actually ship faster.

Question: Why Do You Need QA to Test Everything?

Lean question: Is the QA step adding value, or is it adding time?

If your QA team is a required gate for every change, you have a single point of failure. The QA queue will always be your bottleneck.

What if:

Developers wrote automated tests
Developers deployed to staging themselves
QA focused on high-risk changes and exploratory testing
Small changes went straight to production with monitoring

"But quality!" you say. Counter-question: is quality better when you test everything slowly, or when you deploy small changes quickly with fast rollback?

The data says the latter. DORA research shows elite performers deploy more frequently AND have better quality. Not despite fast deployment. Because of it.

Small batches. Fast feedback. Quick fixes. That's Lean.

Stop Batching Releases

If you're deploying every sprint (two weeks), you're batching. If you're waiting for QA to clear 15 features, you're batching.

Batching feels efficient. "Let's do all the releases at once!" But batching increases risk, delays feedback, and makes debugging harder.

Deploy daily. Deploy multiple times per day if possible. Each deployment is one small change. If it breaks, you know exactly what caused it. If it's wrong, you know within hours, not weeks.

This requires:

Automated tests (yes, investment required)
Feature flags (release separate from deployment)
Monitoring and alerting (know when things break)
Fast rollback (undo is cheaper than perfect)

Not easy. But neither is waiting two weeks to discover you built the wrong thing.

What Success Looks Like (Month 6)

If this works, here's what changes:

Cycle Time Drops

Before: 28 days average
After: 5 days average

Not because people work faster. Because waiting time collapses when dependencies are visible and optimized.

Context Switching Decreases

Before: Everyone juggling 8 things "in progress"
After: 1-2 things in progress, actually finishing them

Shared Services Breathe

Before: ML team underwater with invisible queue of 50 items
After: ML team has visible queue of 12 items, pulls work when ready, has time to think

Communication Becomes Asynchronous

Before: "Quick call?" interrupts happening 8 times a day
After: "Check the board" answers 80% of questions

Work Actually Gets Finished

Before: 23 projects in progress, 4 finishing per month
After: 8 projects in progress, 12 finishing per month

You're doing less simultaneously but shipping more total.

What Will Go Wrong

Let's be honest about this.

Leadership Will Panic

When you make the queue visible, executives will see 47 items waiting for ML and demand you hire three more ML engineers.

Maybe you should. But probably you should first eliminate the 30 items that don't need ML at all.

Visible problems feel worse than invisible problems. Prepare for this.

Teams Will Game WIP Limits

Someone will split one feature into three cards to get around the limit. Someone will mark things "done" before they actually are.

This is normal. Enforce the spirit, not the letter. The goal is finishing work, not optimizing the board.

Shared Services Will Resist Public Queues

"If everyone can see our queue, they'll complain about how long things take!"

Yes. That's the point. The queue length is information. Use it to negotiate scope, hire people, or eliminate low-value requests.

Invisible problems can't be fixed.

You'll Miss the Illusion of Control

Sprints felt organized. Planning poker felt scientific. Velocity charts felt like progress.

Lean feels more chaotic because you're reacting to reality instead of pretending to predict it.

This is healthier but uncomfortable. The board doesn't lie. You can't pretend you're on track when 40 items are blocked.

The Philosophy Shift

The hardest part isn't changing the process. It's changing what you believe about work.

Scrum (done properly) assumes you can plan two weeks ahead, commit to a sprint goal, and deliver a potentially shippable increment. This works if your domain is predictable.

Software isn't predictable. Requirements change. Dependencies emerge. Discoveries happen. Reality intrudes.

Lean assumes unpredictability. Instead of fighting it with more planning, Lean optimizes for:

Fast feedback loops (learn quickly)
Small batches (limit risk)
Visible flow (identify bottlenecks)
Continuous improvement (adapt constantly)

This requires trusting teams to make decisions based on current information rather than past commitments.

If your organization needs Gantt charts and guaranteed delivery dates, Lean will be uncomfortable. Not impossible, but uncomfortable.

Should You Actually Do This?

Honest question: does your company want to improve, or does it want to look like it's improving?

Lean makes problems visible. If leadership's response to visible problems is blame and panic, don't do this. You'll just create visibility without empowerment, which is worse than comfortable ignorance.

But if leadership is willing to:

Accept that visible chaos is better than invisible chaos
Invest in automation and tools
Trust teams to manage their own work
Make decisions based on data instead of intuition
Kill work that isn't delivering value

Then yes. This will work.

It won't be fast. It won't be perfect. It will be better.

The Unromantic Truth

Switching from Scrum to Lean won't solve cultural problems. It won't magically align your strategy. It won't make people suddenly collaborate better.

What it will do is make reality visible. And visible reality is the starting point for improvement.

You'll still have dependencies. You'll still have urgent requests. You'll still have limited resources.

But you'll know exactly where the problems are. You'll have data instead of hunches. You'll be optimizing flow instead of pretending busyness equals progress.

That's not a panacea. It's just honest.

And honestly, that's enough.

I switched to Lean not because it's perfect, but because it's the only methodology that admits software development is fundamentally about learning under uncertainty. The rest is just ceremony.