Skip to content

Latest commit

 

History

History
57 lines (43 loc) · 4.92 KB

little-and-often.md

File metadata and controls

57 lines (43 loc) · 4.92 KB

Deliver little and often

Context

The pattern

Delivering "little and often" has broad benefits across the software delivery process:

  • Incremental software changes: delivering many small software changes is preferable to infrequent delivery of larger changes
  • Incremental team operations: working incrementally (for example re-planning frequently and iteratively refining the architecture and technology choices) is preferable to large up-front planning and design, or long-running delivery cycles

Benefits

  • Increased safety and predictability:
    • Changing less at a time means there is less (per change) to go wrong
    • Frequently-run processes are more predictable (simply because they are run more frequently)
    • The automation which supports frequent changes means less exposure to human error
    • The automation which supports frequent changes supports quick responses if there is a problem
    • Quality checks are applied more frequently
    • Frequent changes make it easier to keep everything up to date
  • Product / service design benefits:
    • Early visibility of changes
    • Early benefit realisation
    • Smaller changes should require less user training, user communications, etc
    • Helps service designers rapidly test hypotheses
  • Cost (in the long term):
    • The automation which supports frequent changes means long-term savings on manual effort
    • Short-lived changes simplifies the technical delivery overhead (merge conflicts, etc)
    • Changing less at a time means less potential for obscure problems (which are difficult and expensive to find and fix)
  • Happier delivery team

Details

This pattern is in essence very straightforward; the power comes in applying it rigorously to everything you do. Judgement is needed when deciding how much to do up front, versus deferring to be done incrementally. But in general the aim should be to do the minimum possible up front and to defer anything which will not alter your immediate actions.

Examples

  • Delivering software. The trivial and obvious example of this pattern is that it is better to deliver software in small increments than to do it in one big bang.
  • Planning. Start by doing just enough planning to forecast the size and type of team(s) you need to get the job done roughly when you want it to be done by. Incrementally refine that plan through (typically) fortnightly backlog/roadmap refinement sessions.
  • User-centred design. User research and design activities (SERVICE-USER, SERVICE-DESIGN) occur in all phases of an agile delivery: discovery, alpha, beta and live (SERVICE-PHASES). Delivery in all phases is done using build-measure-learn loops, with the whole multi-disciplinary team working closely together in all three activities. This approach means that rather than having a big up front design, the design is iteratively refined throughout all phases (SERVICE-AGILE).
  • Technical design and architecture. While some up front thinking is generally beneficial to help a delivery team set off in the right direction, the output design is best viewed as first draft which will be refined during delivery as more is discovered about technical and product constraints and opportunities. See Evolutionary Architectures.
  • Team processes. Great team processes come about by starting with something simple and practising continuous improvement to find ways of working, definitions of done and so on which are well suited to the particular team and environment.

Caveats

  • This pattern must not compromise quality: automation (including of quality control) is essential for safe implementation of this pattern.