Software changes are an integral part of any business. They can be used to improve the user experience or fix bugs in code, but they also need to be delivered on a regular basis.
When you deliver every day, it is often easier for your development team because they are able to find and fix problems more quickly. However, there are some downsides that come with doing daily deliveries too.
In this article, we will discuss why delivering software updates every day is beneficial for businesses as well as identify some pros and cons of doing so. In the end, we will share the decision we took in our specific context.
The benefits of delivering everyday
There are several reasons why delivering software updates every day can benefit for businesses.
Suppose your development team is working with many different systems, and there are often problems when changes need to be made or bugs fixed. In that case, delivering updates on a daily basis can help you reduce the amount of pain that comes along with this.
First, it allows your development team to find and fix problems quickly. This is because they are able to test the changes as they are being made instead of waiting until the end of a sprint or two weeks. As a result, this limits the work in progress and allows for faster releases.
Second, it allows you to keep your software up-to-date and working as expected. If you wait two weeks to deliver updates, then there is a risk that an external change will happen in the meantime such as another company releasing their own update which could break something within your product.
Third, daily deliveries often help with customer satisfaction. Customers want their issues to be fixed quickly and updating software on a daily basis can often help with this.
The downsides of delivering every day
While there are several benefits to doing daily deliveries, it is important to understand the potential problems that could arise from them too.
First, sometimes there isn’t enough time to properly test changes before they are released. This can lead to more bugs being introduced into the codebase and could cause customer satisfaction to decline.
Second, it can be difficult for development teams to keep up with this pace if they are not used to it. It is often easier for them to batch their work together and release updates once or twice a week. This allows them to focus on the changes that they are making and test them properly before the releases.
Third, if something goes wrong with an update, it can be difficult to roll back the change. This is because you would need to have a good testing process in place so that you can catch any potential issues before they are released.
Feature-flags also become an important practice to decouple deployment and activation, keeping a continuous activation flexibility. But feature-flags are challenging to implement from their design, implementation, and on-going maintenance.
Pros and cons of doing in sprint software deliveries
Another option that you have is to do your updates at the end of every sprint, or after two weeks. This allows your development team to spend more time working on their changes they are making without worrying about releasing them quickly. However, this also comes with certain downsides which need to be considered.
First, if the changes that you made in a sprint aren’t ready for release, it can cause problems with your software and lead to bugs being introduced into the system.
Second, this often makes it more difficult to get customer feedback on new features or fixes because they will need time to work through them before releasing everything. If your main objective is to learn quickly from the changes that you are making then this is typically not a good idea.
Third, it can be difficult to predict how much work will need to go into each sprint and knowing which features should be prioritized for release. This is because there isn’t any actual code being delivered in order to test these assumptions, so developers may have no choice.
Fourth, it can be difficult to coordinate work with other teams if they are not on the same sprint schedule. This is because you will need to wait until the end of their sprint before being able to release your changes , for example between front and back-office.
Daily software deliveries: your context, your choice
In conclusion, there are pros and cons to both doing daily software deliveries and in sprint software deliveries. It really comes down to the context of your product and development team that will need to decide which approach is best for them.
In our context, the front and back office were separated into two different contexts with good functional, technical, and temporal decoupling. Our main objective was to move from quarterly releases to more frequent releases by learning as quickly as possible from the user experience.
Hence, we chose daily deliveries.
And you, what will you choose?
References
dailyscrum.com/blog-post/daily-software-updates-vs-at-every-sprint
Nadia Tennich