How is a smaller batch size in Kanban increasing performance?

Question

I have read that a small batch size is executed faster (obviously) than a bigger one.

I have also read that small batches are delivered faster, in relative terms, because they foster a more performant way of working in the team.

Now let's assume a team's throughput is 20 tasks a week. Does this all mean that 2 batches of 10 tasks are executed (as a whole) faster that 1 batch of 20 tasks?

If so, and given work is wip limited anyway, what are the underlying mechanisms that assure such an increased performance?

Am I missing something?

Answer 1

Larger batches have more opportunities for hidden risk.

It's the same concept as projects. Take a look:

Notice a trend? The bigger the project, the less likely it is to succeed. The same concept applies to batches of work. If you conceptualize work in larger batches, then the tendency is to skip out on details.

It's missing the trees for the forest, basically. When you're looking at a single tree at a time, it's easy to see scars on the bark of one of the trees. When looking at a copse at a time, it becomes less likely. When looking at a forest, nigh-impossible.

Answer 2

TL;DR

Does this all mean that 2 batches of 10 tasks are executed (as a whole) faster that 1 batch of 20 tasks?

Generally yes, although the optimal batch size for any given process will depend on other factors as well.

What is Batch Size?

One way to understand batch size comes from Eric Ries' blog post on the subject:

The batch size is the unit at which work-products move between stages in a development process.

The author touts a number of benefits to smaller batch sizes, but the understanding of a "batch" as the unit of work passing each process gate is essential to understanding the rest of the value proposition.

Smaller Batches Reduce Variability

Optimal batch sizing is an outgrowth of queuing theory. The reason you reduce batch sizes is to reduce variability. In agile contexts, SAFe explains the benefit of smaller batch sizes this way:

The reduced variability results from the smaller number of items in the batch. Since each item has some variability, the accumulation of a large number of items has more variability.

Smaller Batches Easier to Estimate and Test Accurately

Smaller batches and more-granular individual work items are also core concepts for the INVEST mnemonic, which says in part:

|--------+-----------+--------------------------------------------------------------|
| Letter | Meaning   | Description                                                  |                                            
|--------+-----------+--------------------------------------------------------------|
| E      | Estimable | You must always be able to estimate the size of a PBI.       |
|        |           |                                                              |                                            
| S      | Small     | PBIs should not be so big as to become impossible            | 
|        |           | to plan/task/prioritize within a level of accuracy.          |
|        |           |                                                              |                                            
| T      | Testable  | The PBI or its related description must provide              |
|        |           | the necessary information to make test development possible. |
|--------+-----------+--------------------------------------------------------------|

If you think about batching as the movement of work items between phase or process gates, then even the tasks within a unit of work often work best when kept small and individually testable. This often has the nice side effect of increasing quality as well as improving cycle times.

Answer 3

Todd and Sarov have provided great answers already. Just adding to that.

Small batch size also provides faster and more frequent feedback loops (or opportunities to react!), as it moves through its workflow or value stream. The faster a batch of work reaches the next stage of workflow or gets delivered to the customer, the faster it gets "reviewed" at each stage. Any defects or gaps in intended function (features or UX related) can be detected and corrective action can be taken. The larger the batch size the longer it takes to do so. To the extent you define "improved performance" as "shorter time to market with the right product", shorter batches improve performance.

This video demonstrates this quite effectively - https://www.youtube.com/watch?v=JoLHKSE8sfU

As for your question - "Does this all mean that 2 batches of 10 tasks are executed (as a whole) faster that 1 batch of 20 tasks?" - you have to also look at your own as well as your customer's cost of coordination and deployment for each batch. It is possible that your development and deployment cadences need to be loosely coupled to adjust to how often your customer can accept new versions of your product. If they cannot accept new versions more than once a quarter (typical corporate IT policy), your releasing weekly or monthly may not mean higher performance for them.

However, if you deploy your weekly/ monthly releases on a staging server and let their users play around with new features and give you feedback, which helps you improve the quality of the product delivered at the end of the quarter, now that is improved performance. The Kanban Method refers to this in its 2-Phase Commit capability. SAFe refers to this as "Develop on Cadence. Deliver on Demand".

In my years of experience in software, to my mind, the biggest challenge that software teams and users have is not knowing what the user really needs till they start to see what they actually get. The faster the dev team can get something to the user, the faster the users can see and react to it and the faster they can start to converge on building what they really need. The smaller the batch size that a team can deliver, the higher their performance.