I started my career with a waterfall style development taking a finished product after extensive quality control to the customer. Release was a major event, marked in our calendar where no one can take days off and the weekends are taken for granted that you will be at work. People spent a considerable amount of time on go/no-go calls and then a marathon effort to make a release happen. The releases were also followed up by hotfixes, bugfixes and minor enhancements which took a toll on the people making it happen.

We think waterfall is extinct now but it is not. There is still a great fear in releasing software to end users. We have progressed so much in software development that a lot of boiler plate is getting taken care by frameworks/tools, extensive automation capabilities help remove toil, abstractions and off the shelf components make it possible to develop and deliver something in matter of days and weeks not in months and years. Combine this with tech practices advocated by XP, we have a very agile tech team.

Photo by Pavel Danilyuk on Pexels.com

No matter what agility comes in technology, the inertia from the business and the product always robs the advantage of agility especially in mid and large organisations. Product teams always want to put a finished product in front of the customer that will wow them, in reality software development never sees a finished product, you just stop giving updates. Tech teams are capable to ship smaller increments of product, in a great frequency in the order of multiple times a day. In a mature continuous delivery enabled team setup, every commit or merge can go to prod within an hour.

Should we call each deployment as a release then. Deployment is a increment to the software, release is a logical grouping of many increments. Branch by abstraction will safeguard existing functionality while new increments are getting delivered and it will be a matter of another small increment to consider it as a release.

I have worked with some teams where the lines blurred, there were only deployments and no releases. One such team had to revamp a user profile page which aimed to declutter the UX and make it more easy to use. The team put a toggle button to preview the under construction page on the current user profile saying “we are revamping the page and let us know how it is coming along”. The designer also asked for feedback from the end user by providing comment ability on the new screen. Along with the comments, analytics was also baked in the new page to learn from user behaviour. This led to super fast iterations of the design as the feedback was instant and from real customers who use the product every day.

Coming back to the inertia from the product to go with a release mindset, this rots the continuous delivery mindset and quickly the teams align to a release mode making it slow, effort intensive and tiring. Decouple releases and deployment, product evolution is supported only when you can iterate as fast as you wish.