Reduce Batch Size in Lean Software Development for Greater Productivity and Quality

 
One of the underlying themes you'll hear about in my writing is the need for doing less. Not less every month or every year, but less before moving to the next step in the life cycle of development. The amount of work released to production or UAT at any one time is the batch size. This batch size usually relates to the number of features released to production during one deployment.
Here are just a couple of items that justify small batches:

• Small batch sizes reduce risk: Simply put, the fewer features promoted to an environment at any one time the less chance of error in the system. This reduces risk. By only deploying a small set of features the effects of that deployment will not be as threatening to the whole system as releasing twice as many features. This makes it easier to locate the source of the problem should something go wrong.


• Small batch sizes increase the speed of feedback: You need feedback for greater speed and higher quality. Increasing the speed of the feed back loop get the developers information faster on the work they finished and makes way for enhancements during the next iteration.


• Small batch sizes minimize development in process: DIP (development in process) is the term used to explain how many features the developers are working on at any time. You could say that every task under development is inventory; and inventory comes at a cost. Once development starts on a bug fix or enhancement, labor costs start to accumulate. So by having 10 items under development the cost is 10x higher than the cost of having one item in development. Releasing less items more frequently to the environment gets users using the features faster and begins to increase return instead of having those costs sitting on someones machine, incomplete.

Keep in mind that deployment comes with a price on the overhead to complete the task. For example, the amount of time a person waits for files to copy; the amount of time users see the "Under Maintenance" message; the amount of time for regression testing; and even the risk involved in a release all add up the overhead. So batches should be small, but not to the degree that the accumulated overhead costs of a deployment should escalate.
We'll explore many more advantages of small batch sizes in the future.