Optimizing Your Release Process with Agile Principles

 

You can hit a nail with a hammer; alternatively, you can use a piece of wood or stone. Both will yield the expected outcome, but there is a high chance of failure with the second method. Similarly, a process is not an essential but a convenient tool that makes work easy and yields precise results.

When it comes to release planning and delivering processes, we can think about something similar. There are many ways that we can deliver a successful release. Nowadays, agile-based software development and releases are common and proven in the industry. Below is how we’ve done it successfully over the years.

Identify a Tentative Release Date:

• In an agile environment, most companies do not depend on strict deadlines to release a product.
• With the aid of PI planning, backlog, and sprint planning, the target release date is identified while maintaining a release-ready product in each sprint cycle.
• The importance of this process is that it always provides what stakeholders require and avoids obsolete requirements and functionalities.
• The development team plays a pivotal part in this process and serves as the main decision-makers on release.
• There is an assigned person to perform releases, either within the team or from outside.
• The development team should constantly communicate with this release manager and identify a probable release date.
• If the team is working on an ongoing project, it is good to identify the next release date once each release is completed.
• This date can be adjusted later based on other factors, such as new feature requests, bugs, or any unforeseen changes.
• It is important to keep all stakeholders informed about the release content and date.
• The easiest way to do this is by creating a release ticket in a ticketing system such as Jira or Azure DevOps.
• This ticket should contain all the stories, issues, and bugs related to the release.
• The release expert owns the responsibility of managing this ticket.

Add Completed and Potential Tickets to the Release Ticket’s Description and Link Them:

• In an agile environment, changes are common, with sudden feature requests, change requests, or bugs added to the release intermittently.
• All these should come as new tickets and be mentioned or linked into the release ticket.
• Each Bug or Story ticket should consist of at least two sub-tickets named development and QA testing.
• QA testing is equally or even more important than the dev task. It is important to validate the intended feature or fix properly implemented in the product.
• Meanwhile, it is useful to make sure that the new addition does not break the existing functionality of the product.
• Sometimes there could be additional tickets, such as UI/UX identification/validation tickets or research tickets.

Tickets that could be included in the release ticket:

• Pre-planned stories/bugs/issues
• Newly added stories/bugs/issues
• Testing tickets — Regression/Sanity

Confirm the Release Date:

• As the release date approaches, consult with the release expert to confirm the date, considering priority tasks and other releases.
• For example, the dev team could work on multiple products, so the release date should be planned based on the most important product request.
• It is important to identify any barriers and allocate sufficient time for a smooth release.
• Also, it is important to constantly communicate with the release expert and confirm the release date while making sure that all expected concerns are addressed prior to the release date.

Regression/Upgrade Testing:

• Once the date is confirmed, it is possible to create regression and upgrade testing tickets. This can be done by QA members of the team.
• Once tickets are created, add them to the release ticket under the “Testing Tickets” section and link them.
• You may already know what regression test is, as its name implies it covers every aspect of the products it ensures all functions in the product work as expected along with new changes.
• Meanwhile, upgrade testing makes sure that there is no anomaly due to a version upgrade.
• It is important to ensure that all associated tickets are in the “Closed” status before starting regression testing.
• If anything unexpected is found while doing testing, it is required to create tickets and decide to address or plan those tickets for a later release.
• This decision should be taken after a discussion with the product manager, Scrum master, release expert, development team, and other relevant stakeholders.
• If all is in order, it is possible to complete regression and upgrade testing. While doing it, it is important to add testing evidence in the respective tickets. This provides proof that all testing is done as required with expected coverage.

Release the Product:

• If everything is in order, the release ticket can be routed for approval, usually given by the product manager or engineering manager based on the composition of the team.
• Next, the release expert obtains approval and releases the product to the public.

Sanity Testing:

• The next step is performing sanity testing.
• A sanity testing ticket should be created and added to the release ticket’s description under “Testing Tickets.”
• This is not very comprehensive testing compared to regression. This testing confirms that vital functions of the product work as expected.
• It is important to carry out sanity testing against the production environment as soon as the product is released to production.

The above-explained process is what we’ve used over the years and has been successful as it addresses most concerns in the lifecycle. Different organizations/teams could use a different process for releases. Hope this will shed some light on someone new to this kind of process. If you are a veteran with experience in the software industry, which approach is your team using? What do you think about this process? Comment and share with me so we can come up with a combined robust process.