Small batches, often ignored in the quest for speed, can help organizations respond to new conditions or knowledge and change course.
While the heavyweight era of software delivery made the mistake of placing far too much value on activity, the agile era puts too much emphasis on speed.
Speed myopia means known good things, like small batches, are framed purely in terms of making teams faster. The other benefits of small batches are ignored and lost in the hurry to optimize straight-line speed.
Small-Batch Benefits
Small batches remove the tangle of complexity that creeps in when you bring too much change together at once. It can be tempting to dismiss this as a necessary part of the process, but it sucks time and effort away from valuable activities.
When Richard Feynman was sent from Los Alamos to Oak Ridge National Laboratory to improve the safety of storage for highly explosive uranium, one key factor was how much material was stored together. Putting too much material in one place could cause it to spontaneously blow up.
Software teams need to understand that this principle applies to changes too. When there is too much change, dangerous interactions manifest themselves at each stage in the delivery process. Merging changes, testing the software, fixing the problems you discover, upgrading a data store and rolling out the new version all occur with higher risk when you batch the changes.
Software might not literally explode, but the cost of motion for a batch of work is drastically higher than the cost of motion for a single change, and it increases superlinearly. Imagine dragging a slider across a bar, with “valuable work” on the left and “rework and remediation” on the right. Batch size moves the slider right in increasingly broad bumps.
Small batches have many technical benefits, and they also help the organization respond to changing conditions and new knowledge by providing many opportunities to redirect their investment. You might reach a goal with fewer changes than anticipated, allowing you to stop early and move to a new goal. Or, you may realize the current approach won’t work, allowing you to try a different approach before you’ve run out of budget.
Most crucially, small batches let you get feedback sooner. This feedback ensures your investment and effort are having the intended impact. And this is the part many organizations fail to connect — at significant cost to their goals.
In the rush to deliver work quickly, organizations aren’t listening for feedback. For many years, intelligent people have been saying you have to go slow to go fast. If you have no time to close feedback loops as you speed through the list of features to deliver, it’s time to discover that “faster is slower,” as Peter Senge, system scientist and author of The Fifth Discipline, put it.
User-Centrism Is Crucial
The DORA research program has also found this concept of slowing down to move faster. The State of DevOps Report introduced the concept of user-centric teams in 2023, and the findings were validated once more in 2024.
The superpower of user-centric teams is that they can achieve the highest levels of product performance with lower throughput. High-throughput teams may be able to deliver far more frequently, but without that crucial feedback, they create low-value features.
Successful features aren’t just those delivered on time and on budget — or incredibly fast. They are features that delight users by improving their ability to achieve their tasks. When you can deliver a high ratio of successful features, you don’t need to depend on the change volume required by hit-and-miss organizations.