ISerialized .Net, C#, Scrum and agile software development

Five key principles to mitigate risk

Releasing new software will always involve some risk of failure whether you do it small incremental releases, or you do it in large cycles with comprehensive testing.  There are however some key principles that will help you lower your risk of failure, principles which are easy enough to remember, but which we often don't follow for one reason or another......

There are a couple of ways you can damage your existing systems. The first is that an undetected bug or unforeseen circumstances requires a rollback. The second is that the release was messed up and the software released to production is not the same as the software released to the test environment. In order to minimise the risk of releasing the wrong software to a production environment, the following policies should be strictly adhered to.

1. Use the same process to release the software to testing and production environments. Ideally this process should be automated to reduce the risk of human error.
2. Release the same software to test and production environments.
3. Keep differences necessary for the different environments (environment variables, configuration) to a minimum in a minimum number of places.
4. Focus with careful scrutiny on any differences between the testing and production environments as they are the riskiest aspects of the system.
5. Keep the testing environment as close as possible to the production environment. Some technologies allow testing to be performed on the production environment with the test and production software coinciding...

Be aware that the risk associated with a release into production is certainly not constant. The risk to the business changes depending on the current context. As such, the business investor and other stakeholders must always be involved in the choice of when a release takes place. [1]

[1] Chris Matts and Olav Maassen - Agile scale fail risk