#delivery #process #lean #agile #core-principles

idea

Batch size is the measurement of a core unit of delivery. This is the size of an increment of work on a product.

Batch size needs to be kept small.

Batch size matter at all level of derivative: the size of tasks being worked on, the size of increments these tasks belong to, the size of product versions these increments belong to, the size of products these versions belong to. You might also re-batch items through the process: the production batch size (decomposition of how you build something) and the transport batch size (decomposition of how you ship it between steps, or to the customer). Transport batch size is more important because it allows overlap of activities and faster feedback.

This creates value for the customer earlier, by ensuring the creation of a valuable smallest increment[3] (prioritization of what's bringing value for the cheapest). This allows faster reduces cycle time, faster iterations and therefore faster feedback, allowing for creation of more value and a better outcome[4].

This also influences morale, with creation of smaller, more attainable goals, and by linking the work done today to the outcome tomorrow. It creates urgency by making smaller tasks with a closer delivery date[5].

This is lowering the associated risks, by allowing to prioritize smaller, riskier batches first, rather than batching them with other stuff and hiding the complexity ; by maximizing the chance of finishing what was started, therefore reducing the likelihood of sunk costs ; by lowering the chance of slippage ; by giving more data, earlier on, on what the status is ; by creating options: more things to pick from, rather than large indivisible chunks.

Smaller batch size allows lower overhead by reducing the amount of scrutiny and orchestration required on each of the different tasks

Batch size economics are a U-curve optimization: the optimal batch size is influenced by the holding cost (the cost of carrying inventory: how much overhead it costs to review an item periodically) and the transaction cost (the cost of processing one batch, i.e. the overhead associated with an increment).

Batch size reducing relies on a looser coupling - if any new feature requires modifying 3 systems then batch size is virtually multiplied by 3. {TODO: write something on coupling and cohesion}

links

Keeping batches small is a key recipe to having working software as soon as possible, and being able to adapt the plan in participation with the client, which link to three out of four of the Agile values.

Having small batch size is helping with Motivation[1] by allowing more humane horizons, and finishing what you started.

Decreasing batch size, and iterating through versions with feedback, is a way of focusing on Outcome over output.

Scrum is working with a fixed batch size: whatever fits in the sprint size.

Batch size is a direct way of controlling WIP: larger batches are automatically increasing the work in process, while smaller batches allow a finer control of what's in flight. Total work in process can be considered a batch itself, and so reducing its size is equivalent to reducing WIP.

[5]: Smaller batch size also creates a non-artificial timebox

Blog / Benefit of small batches on the same topic

references

It is okay to develop in small increments, but deliver in large chunks. Iterations are really just a way to keep track of what the teams are doing.

#NotMyAgile

— Not My Agile (@NotMyAgile) May 25, 2022