Lean + XP isn't for acceleration
Fast is fragile. Flow Is sustainable
You know the feeling. Your team is shipping fast. You squeaked by the first few deadlines, and it seemed like things were working. But the pile of work keeps growing and the pressure to hit deadlines keeps building. Each looming deadline brings a little more stress, a little more anxiety. And each one requires just a bit more hope.
You think to yourself: Why aren’t you going faster?
You’ve tried working longer, measuring engineer productivity and, heck, you even adopted a shiny Agile process promised to help you succeed. But the signs of friction are often already there—more bugs, bigger releases, longer cycle times, and a growing pile of work-in-progress.
This is what happens when teams try to go fast by going fast. You take on more, cut more corners, and push harder until the weight of unfinished work, tech debt, and constant firefighting slows you to a crawl. You’ve been accelerating in the wrong direction.
So ask that first question differently: What’s actually slowing you down?
Lean+XP keep you moving
I’ve worked with Lean and XP teams for a long time. I’ve seen XP deliver incredible results at high speed. I’ve also watched it fail. I don’t think it’s the answer to get a team unburied by debt. But if you’re not fully stuck yet, Lean+XP practices will keep you fast. Not by making you faster, but by making sure you don’t get stuck in the first place.
When teams try to get fast, they usually focus on acceleration. Usually this means they focus on productivity (AKA higher velocity), resulting in more commitments and emphasis on pushing harder to go faster. But really, speed only helps if you’re learning faster too.
But speed is not acceleration.
Speed is maintaining momentum.
Lean+XP don’t guarantee teams go faster in the short term. They optimize for never getting stuck once you’re moving.
Here’s how they work together: Lean eliminates unnecessary work before it can slow you down. (Fewer bottlenecks, fewer wasted cycles.) XP keeps codebases flexible and changeable so that future iterations aren’t painful. (Refactoring, TDD, continuous integration.) Both focus on short feedback loops so problems are caught early, not after months of bad assumptions.
Momentum isn’t about gaining speed. It’s about removing what slows you down.
The real reason teams get slower over time
Every product team starts out moving quickly. New teams, new codebases, new projects—it all feels easy at the beginning.
Inevitably, things bog down. I’ve seen this play out over and over. It’s like being stuck in the mud where your wheels are spinning and engine is roaring but you’re not actually getting anywhere. And the harder you press the gas, the deeper you sink and the more frustrating it is. The only way to regain control is to admit you’re stuck—and stop pressing the pedal. Why?
Because the biggest threat to speed isn’t a lack of force or effort. It’s internal friction.
That MVP you rushed out the door? Now it’s full of workarounds that make every change painful. That feature you built last year? Now it has dependencies no one accounted for. That “small” scope cut? Now there’s rework because it didn’t actually solve the problem.
Most slow teams aren’t lazy or bad at execution—they’re just buried in self-inflicted slowdowns. They could go fast, but every new thing they try to do is like pushing through deeper mud.
And if you don’t deliberately fight that friction, your team will only get slower.
Stop measuring velocity, start watching for drag
Most teams measure speed in terms of how much they’re shipping. Story points, iteration velocity, release frequency. Consulting companies focus on this too, as if there’s any believable correlation between having a high velocity and running a successful businesses.
So start asking “what’s slowing you down?” And if you see some of these things, the warning signs are already there:
Are you working on more debt and bug fixes than new features or 0-1 work?
Do you dread deployments?
Is your release cadence unpredictable?
Does your bug count skyrocket after every release?
Does work get blocked after you start it because of unanticipated scope or dependencies?
Does work sit in progress for weeks?
Slowing down isn’t always obvious, but most teams are constantly accumulating friction and by the time you start noticing it, doing more work or increasing velocity is the worst possible response.
Lean+XP together help teams break this cycle by creating ways to catch friction early and then fixing it, flowing work and preventing slowdown before it happens. Here are some ways to spot friction I’ve learned:
Stop hoarding work: The longer something sits unfinished, the more it drags you down—cluttering focus, increasing rework, and adding to cognitive load.
Tighten your feedback loops: If it takes weeks to get user feedback, your learning cycle is too slow. If it takes days to deploy a fix, your pipeline is slowing you down.
Prioritize tech debt like product debt: If a feature is hard to change, it’s already a problem—even if no one is complaining yet. Prioritize making it easier to change.
Treat process friction as a bug: If something takes longer than expected, don’t just power through. Ask why. Treat slow handoffs, unclear requirements, and rigid approvals like defects to be fixed.
If you’re slowing down, you don’t need a new process—you need to stop breaking momentum
If this sounds familiar then you know trying to speed up didn’t last. If you’re trying to go fast by going fast, you’re just setting yourself up for slowdowns you haven’t hit yet. No amount of tune ups are going to solve your problem.
Every team inevitably slows. But the teams that stay fast the longest treat friction like a critical issue, not a cost of doing business. If your team feels like they’re getting slower, the solution is to stop introducing new slowdowns.
Practicing Lean+XP isn’t magic. It won’t instantly make you faster—especially if you’re already bogged down. But once you get going it will help you keep your momentum.
And in the long run, that’s the only thing that actually matters. The best product teams don’t just move fast—they stay fast.
So I’ll ask again: What’s the biggest source of drag in your team right now? And what’s stopping you from fixing it?