When we're part of a complex system, such as software development, it's easy to believe that doing more in each phase of the SDLC will lead to higher efficiency.

For instance, if we need to set up a test environment to system-integration-test a new feature, and this takes a while to make operational, we'll be inclined to increase the size of the batch of work to make up the time lost setting up the environment.  

Once we start to batch work together, and because it's complicated and requires so much setup time, the thinking is that it won't do any harm to add a bit more to the batch, and so it begins to grow. While this can lead to local efficiency, it becomes problematic when we discover an issue because any reworking will cause delays. And while this may only affect one particular part of the batch, we can't easily unbundle other items, so everything gets delayed until we fix the problem.

As we saw in the coin game, large batches take longer to get through our system. When a problem is discovered inside a batch, this will have a knock-on effect both up and downstream in the process. Reworking will be needed, so people back upstream will need to stop what they are doing and fix the problem. Meanwhile, people downstream are sitting around twiddling their thumbs, waiting for something to do because the batch has been delayed for reworking.

Gated approaches with handovers cause a big-batch mentality because our local efficiency mindset makes us believe that doing everything in one phase will be more efficient than doing it incrementally. The reality is that doing everything perfectly the first time is just not possible. 

In a complex system, when you optimize locally, you tend to de-optimize the system as a whole. Instead, we need to break our big batches of work down into smaller chunks and focus on end-to-end flow through our system, like in the coin game—the smaller batches of coins flow much more evenly. 

There is, of course, a balance to be struck; we need to be realistic regarding what is possible. The smallest chunk possible is a discrete piece of functionality that can be delivered and from which we can gain feedback on its applicability. This feature, or slice of a feature, shouldn't be so large that a work item sits in progress for weeks, or months even. 

Instead, break items down so that they deliver incremental value. The feedback we get increases in value as it travels down the delivery pipeline. The more input that we gain, whether it's direct from our customer through a working software demonstration, through integration with other parts of our system, or actually deployed; the better our chances of success.

For example, why hold off deploying to the production environment until you have a critical mass? Instead, use feature flags to deploy, but keep the feature switched off in production until it's ready for release. We can do this to get critical feedback about system integration and the final step of the deployment process at production time. Plus, with the right infrastructure tweaks to enable us to switch on certain features for a selective audience, we can test our new feature in production before we go live.