Regular small changes: Scale the number of changes rather than the size
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
- Invest in quality
- Evolutionary over revolutionary change
- Minimise unnecessary complexity
- Maximise Team autonomy
- Support autonomy with clear boundaries
- Maximise team empowerment and localised decision making
- Collective responsibility for complete product development - Contending
- Product solution design is driven from within development teams - Contending
- Maximise the Scope of Product Increment - Contending