The smallest useful change

When a team decides a product needs improving, the instinct is to plan a large release. Several months later it arrives, and quite often it is worse.

The reason is not incompetence. It is that a large release changes many things at once, and when the numbers move afterwards nobody can say which change moved them. If three improvements ship together and the result is slightly negative, the team cannot tell whether all three were bad or whether two were excellent and one was terrible. The information that would have told them was destroyed by bundling.

This is why disciplined teams prefer small changes shipped separately, even when a large one would be more satisfying to build. A change that touches one thing produces an answer. A change that touches nine produces an argument.

There is a second advantage that matters more over a year. Small changes are reversible. If one goes wrong it can be removed in an afternoon, which means the team can afford to be wrong, which means they can try things they are unsure about. A six-month release cannot be reversed in any meaningful sense, because by then everything else has been built on top of it. Teams shipping large releases are therefore forced to be cautious, and caution removes exactly the experiments most likely to teach them something.

The counter-argument is real and should be stated. Some changes genuinely cannot be made small: a change of database, a redesign that would look incoherent half-finished. The skill is in telling those apart from the much larger number of changes that only feel indivisible because nobody has tried to divide them.