Before the team releases the application, they will ensure the application is technically sound and that our stakeholders are ready to accept it. Because most testing happens during the Build phase, little may need to be performed now, but some teams may require additional “hardening” activities at this step. By leveraging testing and deployment automation, and by keeping releases small, teams can perform this phase in hours rather than days.
The goals of the Release phase are:
Most testing should occur in the Build phase, but depending on the environment you are working in, additional testing may need to happen once an application is ready for release. The first step is to verify that the application is functional, meets stakeholder needs, and able to handle expected usage volumes. Ensure the following testing is complete:
Key Insight: Test with representative data.
Tests are only valid if they mimic how your users will actually use the application. Applications can act differently when confronted with different data and it is best to find this out through testing rather than by users in production. Therefore test datasets should mirror what you expect in production as much as possible, both in format as well as volume. However, sensitive business data, including user profile information, should not be loaded into non-production environments.
Although the application may be technically fit, it will only deliver value if our users are able to use it. Below are important strategies to ensure the stakeholder community is prepared to adopt the new application:
Start by identifying the complete stakeholder community which will include the end users and their managers, operations teams, help desk personnel, and other related IT teams. Change management plans should include this complete group.
Notify stakeholders of the upcoming application release and any changes to their way of working. Ideally, this communication is performed by “champions”, cultivated within the business, who have been part of the team throughout the project. They can use traditional communication channels within the organization and put the change in context of the business. Common communication techniques include release webinars, corporate newsletters, and release notes.
Before the release, ensure the support team is prepared to respond to end user requests. See this guide for details on how to structure and enable your support team.
Appian is a low training platform with a simple, intuitive interface. To best leverage the Appian platform and deliver a streamlined user experience consider training end users throughout the whole development lifecycle.
These options require varying levels of investment. Therefore, the right option should be chosen based on the complexity of the change involved.
An incremental roll out strategy is one of the most effective ways to manage risk as you deploy new functionality. Consider these common options when formulating your release strategy:
Release the application, or a subset of features, to a small subset of users. This limits the potential impact of unknown issues and allows live feedback which may help uncover invalid assumptions made in testing. Once the release has been validated with the pilot group, it is incrementally released to more users.
First release “read-only” features, such as reports, as a way of getting quick feedback without deploying the full application, or with the “write” features hidden. This technique can also be used to validate a complex data migration.
If the new application is replacing a legacy system, it’s possible to run the new application and the old one in parallel. Once the new system is validated turn off the old one. This makes falling back to the old system easy. Keep in mind: This requires work to be done twice and can therefore only be used in certain circumstances.
Key Insight: Use small, frequent releases
No matter how much teams prepare, there’s always the risk that a stakeholder will have a need that wasn't discovered, or a user will perform a scenario that wasn't tested. When releasing a large batch of functionality to a large user base at once, smaller risks are aggregated together. Therefore, the larger the release, the more testing required and the more communication needed to facilitate with end users. It’s much safer and more efficient to release in smaller batches, more frequently and to fewer people at once.
With the application technically ready to release, stakeholders prepared to receive it and plan in place, it’s time to release the application and deliver value.
The next phase in Appian's Delivery Methodology is Optimize, where you'll learn how to set up application support, establish stakeholder feedback mechanisms, and measure application value.