During the current Dusshera celebrations, our tradition is to have multiple thanksgivings. We thank our house, tools (like scissors, kitchen knives), books, currency, vehicles and anything that helps us earn our livelihood and live comfortably. People whom we employ for domestic help are gifted something as a token of thanks, as they make our lives easier. This was celebrated as a festival in our region called Ayudha poojai and Saraswati poojai. In hindsight, this was nothing but a tradition introduced to value our various stakeholders in life. It instills a sense of gratitude and a reminder every year that we owe our success to our stakeholders. I have seen this first hand when I visited a small restaurant owned by a relative. They were serving unlimited rice in a meal, I asked what if people eat a lot and leave you with less profits, will you add slaked lime to make them feel full faster? The restaurant owner replied, that is killing your customers, it is a form of fraud and you should never do it.

Photo by Greta Hoffman on Pexels.com

On the corporate side, I have never observed the word stakeholder holding a 360 degree meaning. It is almost and always a person who has invested in the company through money, a share holder or an owner. Stakeholders are never employees nor customers nor tools, in other words these are numbers to be used for profit generation. What this leads to is a quarter on quarter rush to increase shareholder value neglecting the real stakeholders. A restaurant treating their customers profit sources will lose in the long term than the ones who think about them as patrons who deserve good hospitality.

Success is a collective construct, keeping that 360 degree view will help to keep decision ethical, create long term loyalty from customers & employees and also keep the workplace morale high. There are very few examples like Costco, Semco who genuinely attempt this mindset and is able to succeed. Many of them are lured by the short horizon profits and lose out in the long run.

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.