Regular small changes: Scale the number of changes rather than the size

From go-ELSE
Jump to navigation Jump to search

Description

A product should be evolved through many small incremental changes rather than fewer but larger modifications. This enables the product as a whole to never be far from a working version.

Rationale

Small changes enable faster feedback loops that increase the rate of learning and reduce the cost and scale of “failure”. Debugging issues that may cross team boundaries are simplified, and remediation waste is reduced.

A short engineering-cycle time enables the ability to rapidly validate small changes, supporting the ability to scale the number of changes rather than their size.

Relevance at Scale

As we scale the system of work, we observe a tendency to increase the size of incremental changes due to the following:

  • Attempting to optimise team efficiency by isolating them from other teams for longer periods of work.
  • An increased transaction cost per change, with a high-effort and time-consuming process to deploy and validate changes to the system.
  • High interdependencies between the work of teams.

Related Principles