This article is the first in a series on small batches.

Has anyone (maybe me?) told you to “work in smaller batches”?

Smaller PRs. Smaller releases. Shorter feedback loops.

Why all the fuss?

This question comes up frequently. So I decided it was time to put down some of the most compelling reasons to work in small batches here. This is the first in what will be a 3-part series on small batches. If you want to be sure not to miss the follow-ups, be sure to subscribe.

Today’s focus is the systemic benefits of small batches. If you’re already familiar with flow engineering you’re not likely to find anything very mind-mending here.

What is a “batch,” anyway?

Before I jump in, though, let me explain what I mean by “small batches.”

The concept of “batch size” comes from manufacturing, and particularly Lean manufacturing, where a batch is the unit of work that goes through, say, an assembly line. In traditional mass production, a batch is may be made up of tens or hundreds of like units, which all go through the same process at roughly the same time.

In software development, the most obvious sense of a batch is a software release. Back in the days of software on CD-ROM, a software deployment was kind of a big deal, and non-reversable. So we’d spend months or years getting everything ready before putting it on a CD and shipping it to customers who would likely use that same software version for years before uprading. In this example, every change that went onto that CD is a “batch.” If you shipped an upgrade version to your customers, that would be the next batch.

These days, when most software is either downloaded over the Internet, or executed directly from the server, we have the option to release software in much smaller batches. Potentially as small as a single git commit.

So this is mostly what I’m talking about with “small batches”: Putting small sets of changes into production, rather than waiting for large sets of changes to accumulate before releasing. Continuous Integration and Continuous Deployment/Delivery are some of the fullest expressions of this concept.

But the concept need not be limited to software releases. Suppose you have a 3-month release cycle that’s beyond your control. You can still benefit from smaller batches within your area of control. You may benefit from creating more, smaller pull requests, even if they batch up into a single release. You may benefit from working in short loops as promoted by Test-Driven Development or The Mikado Method, even if you then batch them into larger pull requests.

With that out of the way… Why should you work in smaller releases, smaller user stories, smaller features, and smaller pull requests?

Less deployment risk

Deployments are inherently risky. As humans, our natural inclination is often to put off risky behavior. Afraid of a bungee jump? You’ll stand on the precipice just a bit longer before finally making the plunge.

Unfortunately, delaying deployments and batching them doesn’t merely delay the risk, it actually increases the risk. If any given feature has, say, a 1% chance of containing a defect that requires a rollback, then waiting to release 10 of them together means you have nearly a 10% chance of needing a rollback.

Faster time to market

You’ve written an exciting new feature. You’re eager to get it in front of customers, so they can enjoy the benefits.

But it’s sitting in a queue somewhere, waiting until the next scheduled release. Ugh. What a waste.

Your new feature isn’t able to deliver any value until it’s deployed. Deliver small changes, as quickly as possible, to increase customer value.

Faster feedback

What if you’re experimenting with a new feature. You don’t yet know if your customers want blue or green text. So you try one, and see what they say. You want that feedback as quickly as possible, right? Waiting until the next batch of changes is ready means you can’t make progress.

This also helps on the team level. The sooner you integrate your changes, the sooner you can get feedback from other teammates or colleagues about your changes, whether that be via code review, or simply interacting with your changes.

Less “inventory” cost

In retail or manufacturing, inventory is physical goods sitting on a shelf. Inventory is a cost, becuase it’s not providing value to anyone. And storing the things often costs money (warehouse or retail shelf rental, for example).

In software, “inventory” is any work that has been completed, but has not yet been deployed. We don’t typically pay rental fees on such inventory, but it does have a cost. Aside from merge conflicts, which I address more completely in the second part, tracking and managing unreleased code is a chore.

And if business priorities change mid-stream, then unreleased work is more likely to be scrapped, having never provided any value at all!

The data says it improves business outcomes

According to research done by the authors of Accelerate, teams that deliver software frequently, in small batches, experience:

• Shorter lead time
• Faster service recovery in case of failure
• Lower change fail rates

But wait, there’s more!

In the second part I continue this list, with some of the more often overlooked benefits of small batches.