I remember at an old employer that we would parcel a number of features into large releases. At the time we thought it was more efficient to do this. We did not have a modular architecture, so everything seemed to be interconnected (often in illogical ways). For this reason, we needed to do a huge amount of analysis to check that we weren’t going to wreck something in the release. Similarly, the regression testing was huge. This had a nasty impact on our lead times, i.e. it took a long time before we could turn an idea into software working in production.
What we did not realise though was that these large releases hit us in yet another place, causing more pain and misery. The long list of features that was waiting on other features all had some kind of documentation, be it a line in an Excel sheet, a fully dressed change request document, or more analysis documentation. This is sometimes called software ‘work in progress’ or WIP. This derives from the name given to inventory in a factory that is neither raw materials nor finished product, but something in between. All work in progress perishes over time. Simply put, it gets out of date. Either business requirements change, or technical systems change, or both. So, someone needs to invest time to get the WIP uptodate. This time is time that is not used to get software working in production.
So, even though we thought these large releases were helping us to increase efficiencies, they were actually slowing us down. Per business-valued working feature delivered to production, we were investing more time than we would have done with small releases.
Large releases can be tricky to resolve, since they often have two or three root causes. Firstly, refactoring to get towards a modular architecture can help. Secondly, regular builds — i.e. more frequent than once every six weeks — will push you in the right way. This is often supported by regular regression tests and some simple configuration management best practices. Lastly, learning to define features as small increments that add value to clients is also vital to reducing release sizes.
In order to achieve this triumvirate of best practices, there is often a tendency to reduce value-added work, e.g. focus on refactoring to the exclusion of client-valued features. Avoid this like the plague — it pushes you into a vicious circle, where the business trusts IT less and less, and as a result, IT trusts the business less and less. Trust is the platform on which agile change is built.