The Power of Small Batches - Lean Software Development

1Batch Size Economics

A batch is a group of items processed together. In manufacturing: parts made in a run. In software: features bundled in a release.

Traditional thinking favors large batches. If it takes 30 minutes to set up the machine, make 100 parts per run instead of 10. Spread the setup cost across more units.

This logic applies to software too: if deployment takes 2 hours, bundle many features per deploy. Spread the overhead across more changes.

But this reasoning misses hidden costs:

Inventory cost: Large batches create large inventory. Parts wait. Features wait. Capital is tied up. Feedback is delayed.

Quality cost: Defects in large batches affect more items. Finding which change caused the bug is harder in big releases.

Delay cost: Customers wait longer. A feature done early waits for the batch to complete.

Learning delay: You don't learn from customer reaction until the whole batch ships. Months of work might be in the wrong direction.

The total cost of large batches often exceeds the saved setup cost.

The Hidden Trade-off

Large batches trade visibility and feedback for apparent efficiency. You feel efficient processing big batches. But you're blind to problems longer, you learn slower, and inventory accumulates. The efficiency is illusory.

2Reducing Transaction Costs

The key insight: if you reduce transaction (setup) costs, small batches become economical.

Toyota's SMED (Single-Minute Exchange of Dies) reduced machine changeover from hours to minutes. Once changeover was cheap, small batches made sense. The factory could make what was needed, when needed, in any quantity.

In software, the "changeover" includes:

Build time
Test suite duration
Deployment complexity
Review process overhead
Release coordination

Each of these is reducible:

Fast builds: Incremental compilation, caching, smaller codebases
Fast tests: Parallel testing, smart test selection, faster unit tests
Easy deploys: CI/CD pipelines, infrastructure as code, feature flags
Light reviews: Pair programming, small PRs, trunk-based development
No release coordination: Continuous deployment eliminates the concept

When transaction costs approach zero, batch size can approach one. This is single-piece flow: every change goes to production individually.

Continuous Deployment

Every merge to main triggers automated tests and deployment. Transaction cost: ~0 (automated). A developer merges 5 small changes per day. Each is in production within minutes. Batch size: 1 change.

The Quarterly Release

Deploys require change advisory board approval, environment coordination, and weekend execution. Transaction cost: days of effort. Releases happen quarterly with 100+ changes bundled. Finding what broke takes days.

3Benefits of Small Batches

When you achieve small batches, everything improves:

Faster feedback: Features reach users quickly. You learn what works. You can pivot.

Easier debugging: When a small change causes a problem, the cause is obvious. Rollback is simple.

Lower risk: Each deployment is a small change. The blast radius of a bug is limited.

Better flow: Small batches move through the system faster. Lead time drops.

Less inventory: No large piles of work waiting to be released. Capital isn't tied up.

Higher quality: Small changes are easier to review. Defects are caught earlier.

More flexibility: You can reprioritize quickly. You're not locked into a large release.

Team morale: Shipping frequently feels better than waiting months for a big release.

The ultimate expression is continuous deployment: every change goes to production when ready. This is single-piece flow for software. No batching, no waiting, no coordinating releases.

If continuous deployment seems impossible, ask: which transaction costs would need to reduce? Then work on reducing them.

Start Where You Are

If you deploy monthly, try deploying weekly. If weekly, try daily. If daily, try continuous. Each step reveals obstacles to the next step. Solve those obstacles progressively.