This article elaborates on ideas that have emerged from a discussion with several intelligent members of the Kanban community. I sum up the ideas and expand the thoughts with my own experience. Let me know what you think.
What does batch size mean?
Batch size is the number of things at a time with which you go through one process or subprocess. Example: If you have a bakery that bakes bread then the batch size is the number of loaves that you can bake in the oven at once. You fill the oven with a batch of loaves, let them bake, take them out again and sell them.
This is batch size in manufacturing (I treat a bakery as a special case of manufacturing, here). However, what does batch size mean for a development organization?
Unlike in manufacturing, a batch of things to develop is not uniform. Development is the activity that finds out how to do something, how to come from a problem to the solution of that problem. In development, larger batch size means: solve more different problems, not: solve the same problem again and again.
Example: If a customer asks you to develop a software system that allows her to manage a fleet of trucks with cargo, this is a large problem. It contains several sub-problems like these:
- Keep track of how many trucks they have
- Display the location of each truck
- Track which and how much cargo is on which truck
- Find out the fastest or cheapest route for new cargo
- Find a quick replacement for a suddenly broken truck that carries frozen fish
Each of these problems is different. If you solve them in a large batch (say, you go with all five subproblems through your entire development process at once), it will cause a potentially hard strain for your organization. Why is that?
Large batch means more people
Larger batches mean that you need more people to take care of the effort. If you want to solve five problems at once, you need more people than if you try to solve one problem at once. These people need to communicate with each other. Communication cost increases with the number of connections between people. n people on a team have n*(n-1)/2 connections, so the communication cost goes up with n square, not with n.
Large batches make software unmaintainable
With increasing batch size, more and more components inside your software will have to be changed. The larger the batch size, the more connections people will create between the components under change. You will get a mesh of components and connections that quickly becomes unmaintainable if you allow your teams to solve too many problems in one go. „One go“ can mean one phase/iteration/sprint of your project or one release of your system or whatever causes batching in your organization.
Large batches make ideas old and stale
A large batch of problems takes a long time to get solved. At the end, your team presents the ideas and solutions they have found to the stakeholders who have stated the problems.
Now, the larger the batch has been, the older the ideas and solutions will be at the end. The stakeholders will be confronted with ideas that are old and stale – the market may have changed their view in the meantime so that the team will have to re-think everything which causes a potentially large cost for rework.
If you keep batch size small, you will enable teams and stakeholders to establish continuous, on-going, alive conversation. Ideas will be fresh and up to date, reflecting the needs of the market.
Large batches let developers go astray
When the team goes through a long development phase, working themselves through a large batch of problems, they present their solutions at the end. It may turn out that the ideas or solutions are not really appropriate to the problems so that the stakeholders will give corrective feedback to the team.
The larger the batch, the less feedback the team will get because the time between feedbacks goes up so the frequency of feedback goes down. This may cause the team to go astray, at least the stakeholders may perceive that and say „hey, this is not what we were trying to get – the team has in fact solved entirely different problems than we thought!“.
The smaller the batch, the more frequently the stakeholder feedback will come and keep the team on track.
Increasing batch size increases risk
Changing a large system is risky. Any change can make something work and break something else at the same time. The more you increase batch size the greater the chance to undermine previous work. People tend to make mistakes when the number of things that they work on at the same time is so large that they lose sight of the big picture and they feel overwhelmed with stuff.
Keeping batches small will enable people to focus on what they do and thus will make breaking changes significantly less probable than before.
Reduced batch size encourages simplification and automation
When a team works on a small number of problems at once, each problem can become so small that it becomes simple. Thinking in small batches encourages people to split problems into more simple problems that can easily be solved (see for example the article Twenty ways to split stories on Bill Wake‘s XP123 website).
To go even further, after people have solved 3 or 4 of those simple problems, they will go and automate recurring solutions, e.g. they install a continuous build server that gives constant and almost free feedback after each commit operation in the source code control system.
Simplification and automation reduce development costs significantly.
Smaller batch size fosters design discipline
Smaller batch size disciplines designers to simplify their design. Batch size reduction is a defensive approach that can be used effectively for guarding against defective or flawed design of a software product. The quality of a software product is centered in software design. The simpler the design of a software product, the better the software product.
Imagine a waterfall project where the design phase is long – that means, design batch size is large. Many problems have to be solved over a period of months. How much pressure do you feel as a designer to keep your stuff simple? Facing such a complex batch of requirements and boundary conditions, a designer can easily believe that an equally complex product design is justified.
So, keep batches small so that designers feel a small and adequately simple design is what the product needs.
Too small batches reduce value for the customer
Imagine you are a customer and want a team to build a word processor for you. Imagine that team releases a first version that allows you to write text, format text and check text for correct spelling. However, the first release of the new word processor does not allow you to save the text on a file – wouldn‘t you be disappointed? This can make you think that the batch size was too small this time.
The trick is that this time we talk about a different kind of batch: It is not the development batch but the release batch. This batch should of course be so large that it makes sense for you as a customer – decreasing the size of this batch below a certain point reduces the value of the released product. Maybe, you would have accepted a first version that allows you to write, format, save and print text, without spell checking.
Release batch size need not have anything to do with development batch size – they can be independent of each other. Both should be small but release batch size cannot be infinitely small: Value is more important than batch size.
