In part four of our Agile Teams Journey series, we’re going to discuss the release of your software product. There has been so much time, effort, and collaboration between teams and the client that has led up to this point – and it’s finally going to get put out into the world!
As a refresher, in part 1 we discussed the discovery phase with streamlining your tech products by pursuing a minimal viable product (MVP); part 2 dove into the alignment phase by developing a strategic release plan and setting the right goals; part 3 focused on agile methodologies and the execution phase.
Understanding some key best practices and considerations in the release phase will help support a successful launch and enable you to continue to deliver real results for end-users.
It is important to mention that there is a continuous – non-stop – cycle of execution and release phases throughout the entire project, where coordination and communication between Development Teams and Client Teams are crucial to guarantee a successful delivery. The Release Phase will be talking about major releases, where the product will be used and run by other users.
Verify the Solution is Ready for Release
Create a “solution release” checklist in order to discover everything you need to prepare your team for success:
- Plan the devs’ release schedule – Your solution release schedule needs to be planned and communicated. Many organizations have blackout periods where teams are not allowed to deploy into production. There are many strategies that organizations may choose to adopt when it comes to scheduling releases, including release trains, release streams, ad-hoc releases, and release windows.
- Schedule solution release – The release of an individual delivery team’s work needs to be scheduled so that it does not conflict with the releases of other teams or some important date for the business.
- Determine production readiness – Part of the release process is to verify that the solution is ready to be deployed and that the stakeholders are ready to have it deployed to them. The bigger and more infrequent your releases, the more this becomes an issue. Before a new release, make sure the QA has done the regression testing, and that your client has approved the test results. It’s a good practice to have a beta app for testing so that your client can get to know the value that your team has created.
- Support the delivery team – The release management team, when a separate one exists, will work closely with the IT delivery teams to help them deploy successfully. This help may take the form of coaching the team on deployment techniques, planning, and even working with them to automate their deployments. The release management team will often help with deployment testing, the verification after the fact that deployment was in fact successful.
Create a Release Plan for success
In part 3, we discussed the importance of creating a release plan at the start of the project so that it could be updated throughout so that it always reflects the current expectations about what will be included in the release. The goal of release planning is to determine an appropriate answer to the questions of scope, schedule, and resources for a project. In conjunction, an adoption plan should be developed and completed at the beginning of the release phase. This plan should outline considerations such as deployment goals, validation, requirements, and risk management. We propose the following guidelines for your releases:
- Every sprint will finish with a new TestFlight release in the hands of beta testers.
- Estimate a maximum of one week to gather feedback from the testers.
- Estimate a maximum of one week to incorporate feedback and fix minor issues. If it’s necessary, get client approval by email, for example.
- Create the release notes.
- If enough minor bug fixes are done within a week, you can do a minor release at the end of the week.
Taylormade the appropriate Adoption Plan
The Adoption plan contains vital information on how the final solution will be deployed but more importantly, how the knowledge will be transferred to end-users.
A good Adoption Plan should cover the Deployment goals, requirements, risks involved, and how they are going to be mitigated.
Knowledge transfer and training sessions are key factors in determining the success of the Adoption of the new solution. Training sessions should include a clear scope, materials, a clear schedule, and if it’s necessary a Training Environment.
As we have talked about in previous posts, Communication is King and a key part of the success of Deployment is communication with all stakeholders. For that reason, a clear communication plan should be in place with accurate information regarding events, audience, and owners.
Good Communication and Collaborative working are your team’s ticket to success.
Stay tuned for our final post on this series, where we’ll be discussing the Evolution phase. Until then, please connect with us on LinkedIn or visit us at WillDom.com.
