26 January 2021
When is it reasonable to wait before the next software release?
The most important part of each project is the premiere of the new software release. A new version of a product, application or system on which developers have worked intensively. The so-called “going to production” is often associated with excitement, adrenaline and, in my personal opinion, a kind of inner joy that it is finally time to present it to the world. But is it always good to push the next software release to be deployed as soon as possible? From the article below, you’ll learn why sometimes it’s good to calm down and wait a little bit before going live with the next software release.
A debut or a new version of the product brings joy and excitement as well as a dose of stress and responsibility for success or failure. What will be the reactions of end users to what we have been working on for many weeks, months or years?
To release or not to release?
If you are a Product Owner,it’s natural that you always want the next versions of your software to be released as soon as possible. However, it’s good to be aware that there are situations when, paradoxically, you can save time and money by… not doing so and holding off the release a little bit. Being a Business Analyst puts me in a position to share some insights regarding those situations. So in this article, I will present to you some cases and will suggest what you can do to try and convince other stakeholders to postpone the final deployment.
Cyberpunk 2077 case
Most of us probably remember the most famous game premiere of 2020. The release of the long-awaited Cyberpunk 2077 just before the festive season resulted in a lot of negative comments over the quality of the game and the problems some users faced. It also caused some decline in the stock exchange quotations of this title’s publisher and certainly, a decline in the confidence gamers and investors had in the company.
Nevertheless, the game was also a huge success – we must admit that 8 million pre-ordered copies of the game are impressive. The question, however, is whether everyone can afford such a launch or release of a new version that will cause an avalanche of negative comments?
“The most important thing in the journey is to complete it” – Genghis Khan once said.
Perhaps, Cyberpunk’s publishers were guided by the quote above. Therefore, they wanted (or had to) release this game at any cost. But let’s leave this launch day aside, a lot has already been said about it. History shows that not only the premieres in the gaming world can be stormy…
When the software release rush is not favorable?
It is worth recalling two of the non-software related situations that are meaningful when talking about the rush. The first example can be the great service action performed by one of the biggest car manufacturers. Toyota was urged to fix gas pedals on 4 million vehicles due to an issue with the accelerator pedals in 8 models of the company cars manufactured between 2005 and 2010. Another example may be the new model of the Boeing 787 Dreamliner plane, which had to be grounded immediately after its premiere due to some failure.
But let’s go back to the IT world, where there are many new products and improvements to already existing versions of systems or products appearing throughout the year. A good example is the annual presentation of new mobile phone models. It happens that the presentation of the new device is followed by the appearance of a new version of the operating system. It often happens that just a few weeks after introducing the “final” version of the OS, a big update is needed due to flaws in this system discovered by end users.
Let’s also take a look at some software produced in Poland. In 2017, a new vehicle registration system, CEPiK for short (Polish abbreviation of “Central Register of Vehicles and Drivers”) was launched. Unfortunately, as soon as the system was launched, there were some big problems with its functioning. Many car owners weren’t able to register them or even perform a technical inspection of the vehicle…
From my personal experience, I need to admit that I also participated in the release of a new product after which we had to spend another two weeks fixing all the faults that appeared when the so-called real data was entered into the system. It appeared that its amount was so overwhelming that the system was not prepared for that.
As you can see, there is one conclusion from all the aforementioned stories – each new release carries a high risk of failure or detection of serious defects by the end user. These may cost us the loss of our customers’ trust. Those companies I mentioned were able to cope with these problems and regained the customers’ trust. However, it should be remembered that they are big fish with many years of reputation in their fields. Therefore, it is easier for them to cope with some serious faults. Unfortunately, not everyone can “afford” to lose the trust of users. So, how to prevent it or try to minimize the losses that can be caused by the low quality of a new version of our product?
Experience is the key
The most important elements of each project are… the people involved in its implementation. In my opinion, attention should be paid to the more experienced ones, and I do not mean the length of service, but the number of different types of projects and situations they have dealt with. Why is it so important? Let me quote the basketball master here – Michael Jordan:
I have suffered failure after failure in my life. That’s why I was successful.
People who have experienced unsuccessful issues in their professional life will have knowledge about what went wrong and how to prevent it in the future, so it is worth having them in the team. At least at the beginning of the project, as they can help you determine the processes. As mentioned before, I personally participated in the release of a new product that needed some quick fixes.
Thanks to this, I have gained some experience and I can prevent a similar situation in subsequent projects. The next step is to automate the processes wherever possible.
The role of Continuous Integration and Continuous Deployment
This is where Continuous Integration (CI) comes in handy. It’s a tool used by DevOps, in which after each commit/merge process, the system starts the compilation process, unit tests and any static analysis tools used. Any other quality-related tests that can be automated are also performed.
The next step is (or at least should be) the implementation of Continuous Delivery (CD) or even Continuous Deployment (CD). The difference between these two methods is to decide whether we want to automate the entire process from the development environment to the production environment (Continuous Deployment) or leave yourselves the option of manual update of the production environment as it is in Continuous Delivery.
But what if we do not have an experienced person available and/or we do not have sufficient budget or time to allow ourselves to implement the entire CI and CD process?
Then you should bet on people who will take care of the quality of our product and will not be afraid to block the next issue. Of course, making such an important decision as stopping the production requires a solid justification.
Not releasing a new version of the system may be associated with a huge risk, as well as financial troubles and image loss in the eyes of not only users but also the project’s sponsors. Working in an agile environment, the final decision regarding the release of a new version is always made by the Product Owner (PO). The person who should have a full picture of the current situation regarding the state of work progress and the quality of the product being developed. There are some arguments that may convince the PO to suspend the new release.
What arguments can appeal to the Product Owner not to release a new version of the software:
- critical errors/bugs that prevent the safe use of the system;
- failure to complete the entire critical path for the end user;
- untested new functionalities relevant to the critical path;
- new functionalities that do not meet the needs of the end user;
- failure to provide end users with sufficient knowledge about new functionalities;
- failure to provide sufficient knowledge to the maintenance team (if designated);
- lack of access to infrastructure, whether it is in the process of testing – only one platform has been tested or during deployment;
- no possibility to monitor, verify, uninstall and roll back the new version;
The first point on this list does not require much comment. None of us like to receive a 404 error when visiting a website. Also, no one likes any cases of a mobile application crash that make users start the process from the beginning (for example, buying something in an online store). Non-working visible buttons are also annoying.
The next points from this list related to the critical path are equally important because on their basis we have built the entire process that our user will follow and they should not encounter any gaps or problems in this journey. It is also a big risk to release a new version without testing the functionality related to this path. One of my teammates has already written an article on why feature testing is a must when you add anything new to your app.
Another important element that may have an impact on blocking a release is the failure to provide sufficient knowledge about new functionalities to end users and, if we have it, the maintenance team. Remember to inform our stakeholders about the new functionalities that will be introduced in the next version so that they are not surprised by changes in the processes.
The last element mentioned above is the lack of access to the test environment, but also problems with the infrastructure for the release. Paradoxically, it is important to be able to roll back our changes and restore the previous version of the system. Sometimes it happens that the test environment on which the system worked flawlessly may differ significantly from the production environment, where undesirable effects may occur, in which case it will be required to roll back to the previous version of the system.
As you can see, there are many reasons not to release your software as soon as possible and at any cost. It’s good to consider the so-called pros and cons. Nevertheless, a development team that is responsible for delivering a high-quality product should have the courage to inform the Product Owner whether it is reasonable to proceed with the premiere of the newest software release. Therefore, dear colleagues – have the courage to block a release when you see that something is not working as it should. And you, dear customers, Product Owners and Project Manager – try not to be upset when the Quality Assurance team doesn’t give the green light to proceed with the release. You can be sure that we do it only for the greater good of yours and the satisfaction of your users, to ensure that our common goal is achieved. As Ludwig Purtscheller once said:
The character of man is expressed not only in boldly deciding to attack, but also in the ability to give up.