Smaller frequent releases


Normally I have seen that large organisations have such a heavy processes that they go for monthly or quarterly releases OR even worse, they release every 6 months. This means they are doing more in each release. Due to this, they keep on accumulating risk, rather than splitting the risk over many small changes

If you are not finding time to complete your definition of ready or definition of done with simple things like code reviews, design reviews, demos, unit testing and the likes than it is a symptom that you are not only doing lots of changes in a release but also trying to run multiple releases in parallel

You will be surprised that by just shortening the release window and reducing things in parallel, you can smoothen so many of those processes


Advantage of the shortening the release cycle and reducing things in parallel are simple

  • As you are doing less in a given release, you are not that much worried about regression cycles
  • You have a laser focussed team, who is working on making sure they propagate changes to production and take pride in seeing things working for end users
  • Doing an MVT for a new change is much easier, if we are dealing with 2 change as oppose to 100 changes

One of the biggest capability you need for frequently release is ability to deploy to production faster. Your deployment needs to be atleast 90% automated to go in this direction. Other thing to invest in will be testing automation but that is not mandatory as you are minimising regression risk by doing small changes

Please share your thoughts on your experience in this space