By Nick Butler
Tags: Agile , Development
Do you work in an organisation struggling to do more with less? We come across many projects where organisations have tossed in additional resources to meet a looming deadline, pinching pennies from elsewhere and creating stress for all, without solving the underlying problem. Reducing your batch size is a key way to deliver faster, cheaper and better.
How to reduce batch size in Agile software development
Get five tools for reducing batch size, and take a quiz to find out how effective you currently are at keeping your batches small.
Working with small batch sizes (a batch is a unit of work that passes from one stage to the next stage in a process) has tremendous impact. It improves flow and lets us deliver quickly and reach project completion earlier.
In software development terms, a traditional process means a team will define all of the project’s requirements first, complete all of the design next and then finish all of the coding before testing.
In contrast, working in small batch sizes means completing, for example, 10% of the design, the development and the testing before moving on to the next 10% of the product’s features.
There are very good reasons why batch size is important.
First up, when we work with small batch sizes, each batch makes it through the full lifecycle quicker than a larger batch does. We get better at doing things we do very often, so when we reduce batch size, we make each step in the process significantly more efficient.
Smaller batch sizes also mean you’ll deliver faster and reach project completion earlier. Since work on a feature isn’t complete until it is successfully running in production and generating feedback from customers, large batch sizes delay that essential feedback.
Batch size can be one of the most difficult things to optimise but it is economically crucial. Numerous studies have proven that larger batch sizes lead to longer cycle and delivery times – and a longer wait to find out if you’ve delivered value to your customer.
There’s a bunch of beneficial outcomes that come from working with much smaller batch sizes than traditional processes recommend.
Some of these benefits are:
All this makes for better economics. Donald G. Reinertsen’s diagram uses testing as an example, and shows the direct links between a smaller batch size (which results in smaller changes, fewer open bugs and faster cycle times) and improved economics.
We’ve even got mathematical proof that you should reduce your batch size!
First published in 1954 and proven in 1961, Little’s Law has been used across many industries. At its heart, it deals with queuing systems, which is what coding-oriented projects also have to deal with. Little’s Law means that if you reduce your cycle time by the power of 10, you increase your capacity/production by a power of 10.
What is an ideal batch size, and how do I reduce my current batch size?
Reinsertsen recommends reducing your batch size by 50%. You can’t do much damage in this range, and the damage is reversible. Observe the effects, keep reducing, and stop reducing when total cost stops improving
Batch sizing is very much a horses for courses endeavour. Some large projects might favour a 30 day sprint, but for most of the projects we’re involved in, we’ve found the sweet spot is two weeks.
If you’re using Agile, you should be working with small batches already. (If you’re trying to implement Agile but using the same batch size as a traditional project – that is, 100% – Agile will not work!) However, it’s important to remember these guidelines when you’re setting up your next project:
The last word goes to Reinertsen and his video: The practical science of batch size. It has all you need to know about batch size – how it works, why it works and what to do next.
How to reduce batch size in Agile software development
Get five tools for reducing batch size, and take a quiz to find out how effective you currently are at keeping your batches small.
Reducing batch size to manage risk: Story splitting case study
Why small projects succeed and big ones don’t
Prioritise user stories and produce more value sooner
The difference between prioritising and ordering
Dave Snowden on how to achieve change in complex systems through small nudges
