Agile IQ®

Smaller Work Batches

Influencing Behaviour. Secondary Factor.

Overview

Working in small batches is one of a set of capabilities that drive higher software delivery and organisational performance.

What are “small batches”?

Working in small batches is an essential principle in any discipline where feedback loops are important, or you want to learn quickly from your decisions. Working in small batches allows you to rapidly test hypotheses about whether a particular improvement is likely to have the effect you want, and if not, lets you course correct or revisit assumptions. Although this article applies to any type of change that includes organisational transformation and process improvement, it focuses primarily on software delivery.

Working in small batches is part of lean product management. Together with capabilities like visibility of work in the value stream, team experimentation, and visibility into customer feedback, working in small batches predicts software delivery performance and organisational performance.

Why work in small batches?

Traditional project teams work is done in large batches is because of the large fixed cost of handing off changes. In traditional phased approaches to software development, handoffs from development to test or from test to IT operations consist of whole releases: months worth of work by teams consisting of tens or hundreds of people. With this traditional approach, collecting feedback on a change can take many months.

In contrast, agile team practices, which utilise cross-functional teams and lightweight approaches, allow for software to progress from development through test and operations into production in a matter of minutes. However, this rapid progression requires software teams to work with code in small batches.

Benefits

Working in small batches has many benefits:

It reduces the time it takes to get feedback on changes, making it easier to triage and remediate problems.
It increases efficiency and motivation.
It prevents organisations from succumbing to the sunk-cost fallacy.

Source: Google Cloud Architecture Centre