Get Feedback Early and Often

Gain feedback by frequent and early releases of functionality rather than 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.
  • Early visibility of platform costs will help make informed decisions about future solutions

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

Points for discussion

  • Could you do daily releases?

results matching ""

    No results matching ""