The Appian Delivery Methodology Part III

Part I: Initiate    Part II: Build    Part III: Release    Part IV: Optimize


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:

  • Ensure technical readiness by testing for function and performance.
  • Develop a deployment plan and release strategy.
  • Communicate impact of release to the business and relevant stakeholders.

Ensure Readiness

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:

Ensure Technical Readiness

  1. Perform end-to-end functional testing - Perform final regression tests to verify that the application is functional. When possible, use automated tests to cover core functionality, augmented by manual testing for complete coverage. If your test strategy includes parallel independent testing, this will need to be completed.
  2. Ensure stakeholder satisfaction - Confirm that the Product Owner has accepted the application and all User Acceptance Testing is complete. Ideally, acceptance testing occurred throughout the development process, so now you are confirming the reviews were completed by all relevant stakeholder groups and performing any final demonstrations.
  3. Validate data migration procedures - If the release requires you to migrate existing production data to the new application, test these procedures and use automated reviews to ensure the migration completes successfully.
  4. Develop and test your deployment plan - Ensure the deployment plan is complete by testing in a production-like environment. All participants required to execute the plan—including support teams (networking, DBAs)—should be included in these test runs and understand their responsibilities. Ideally the deployment process is automated so these tests require minimal effort.
  5. Perform concurrent load testing - For high-volume applications, test to verify the application’s ability to perform at the expected peak volumes. This testing should be performed in an environment that closely mirrors the configuration of the production system. At a minimum, perform an updated hardware sizing analysis for the expected volumes.
  6. Provision Users - Ensure that a process is established to provide access to users of the application. New users should be able to leverage a documented process to request access to appropriate authorization roles. When an application is initially released, users may need to be provisioned in bulk. Establishing a plan well before going live will ensure that users will have the correct access on day 1.

BulbKey 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.

Prepare the Business for Change

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:

Identify all the stakeholders that may be affected

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.

Communicate the change

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.

Prepare the support team

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.

Educate and train end users

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.


  1. Engage with users and stakeholders early and often with demonstrations.
  2. Identify opportunities to "train the trainer". Encourage key users, stakeholders and other non-developers to participate and drive future training sessions.
  3. Improve usability and consistency by adhering to design best practices including the Appian style guide.
  4. Build an intuitive application and invest time to truly understand users (an intuitive application requires less training).
  5. Many applications often have a significant impact to day-to-day client operations. Coordinate closely with business users, project managers and executive stakeholders.


  1. Help text built into the application.
  2. User guide and application documentation. 
  3. Virtual online training videos.
  4. Formal classroom training.
  5. Remember to provide an overview of core Appian concepts. (Use the Appian Quick Reference Guide as a starting point)
  6. Whenever possible gather and incorporate user feedback.
  7. Avoid information overload. Keep documentation and presentations high-level to avoid overwhelming users with detail.
  8. Screenshots and recorded videos are effective but should be used sparingly as applications evolve rapidly.
  9. Consider using a dedicated training environment and build time for user training into project plans.
  10. Tailor your approach and documentation to the audience.

These options require varying levels of investment. Therefore, the right option should be chosen based on the complexity of the change involved.

Deploy the Application

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:

Determine Your Release Strategy

Pilot Release

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.

Read-only release

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.

Parallel run

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.

BulbKey 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.

Release Application

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.

Release Checklist

Ensure Technical Readiness

  • Have you run Appian Health Check in a production-like environment and resolved risks it identified?
  • Did end users have a chance to perform hands-on testing of the application?
  • Did the implementation team address critical feedback via functionality or training?
  • Did this testing include all relevant user groups (personae, geographic regions, etc.)?
  • Did the volume of test data mirror the data volume you expect in production? When applicable, did you analyze historical data (ideally five to 10 years’ worth) to validate future volume assumptions?
  • Did you validate performance of the system based on the concurrent user activity volume you expect in production? Did you test for volume beyond your expectations (e.g., 1.5x, 2x, etc.)?
  • Do you have a plan for the deployment day/weekend? Do all the necessary supporting parties have knowledge and awareness of their responsibilities (networking, DBAs, etc.)?
  • Have you verified hardware and infrastructure sizing needed in production? What about three to six months out and beyond?
  • Has a method been established and tested for provisioning all users?

Ensure Stakeholder Readiness

  • Have you run Appian Health Check in a production-like environment and resolved risks it identified?
  • Did end users have a chance to perform hands-on testing of the application?
  • Did the implementation team address critical feedback via functionality or training?
  • Did this testing include all relevant user groups (personae, geographic regions, etc.)?

Up Next

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.