One of the greatest challenges facing any software company is the risk associated with new releases. As a responsible software development team, you should put just as much emphasis on delivery of the software as you do on development.

The most direct and deliberate way to mitigate the risks associated with software delivery is to stick to the mantra of “Release early, release often”. The surest way to accomplish this is to repeatedly build *and* deploy the minimum viable product and the smallest possible change. Doing this mitigates risk by reducing the impact of a rollback to “just a single feature”.

The reason that this is so important is that it allows you to stick to short and simple release dates, which encourages and enforces predictability into your software development. Your release cycles should be small and take place at the smallest sensible interval on a sliding scale between “as soon as the feature is QA’d” (which represents the least possible risk and the smallest possible change) to “as soon as the current iteration or sprint is complete” (which is often a fair compromise allowing a more coherent shipped change).

Ensuring that your releases happen on simple and consistent dates (for example “Every Tuesday”, “Every day at 7pm”, “Every time QA signs off a feature”) maximises transparency for the rest of your organisation and helps build trust in too-often-opaque software development departments. In addition to transparency you will also gain a tight appreciation for scripting your release processes and increasing your comfort in your deployments due to the increased and and consistent nature of installing software. This focus will quickly surface any points of friction in your software release process that need improvement.