Release Early and Often

Prefer early and frequent releases of big functionality pieces to Big Bang releases.

Rationale

Early and frequent releases provides feedback earlier, code level integration is easier, course corrections can be made sooner and provides business value sooner. Problems are easier to identify and resolve in smaller changesets.

Implications

  • Requires the automation of repetitive tasks.
  • Encourages splitting big project into a set of smaller features.
  • Requires switches to disable incomplete parts of functionality or to make a rollback.
  • Requires regular assessment of feature flags and removal of the obsolete ones.
  • No long-term development branches (and merges) needed.
  • Requires an automated, version controlled, configuration management strategy
  • This principle applies to all environments in the path to live, not just the production environment.

Examples

  • Coming up with a very pure MVP is important a good example is Made To Measure Roller Blinds, where functionality was added slowly over a few weeks
  • 1jl wishlists pure MVP
  • OCCO - backend code in production, international 1man 2man before the site was ready
  • A bad example was Payment where the code was complete way before it was needed

results matching ""

    No results matching ""