Engage Client Post Live Support Team
Once the User Stories and other Product Backlog items have been built, tested, and accepted by the Product Owner, the application is ready to be deployed into production. A go/no-go meeting should be held by the Scrum team and other key stakeholders to review any open issues, open risks, and unresolved defects to collectively decide if the application is ready for production. As part of that meeting, post-go-live support processes need to also be reviewed by the development team and the customer teams who will be owning the application.
Pre-go-live planning, which should include a handoff and knowledge transfer to the teams who will maintain the application after deployment, will help reduce interruptions and customer service issues for end users. The specific steps for go-live and the owners responsible for executing the steps should be identified, as well as any post-go-live smoke tests or other tests to validate the production deployment. There should also be steps for post-production release monitoring, to identify any adverse impacts or issues experienced by end users.
The team responsible for maintenance should participate in the go-live activities to observe the process and develop the skills necessary for the next release, which they will own. Pega GCS should also be informed and included in the pre-go-live and post-go-live planning.
Having plans in place for go-live and post-go-live verifications will mitigate risks significantly, as the team will be prepared with contingency plans and potential workarounds which may need to be executed in the event there are issues. Having a well-trained team with a solid go-live and post-go-live plan is prudent risk management.
Following a “go” decision by the Scrum team and key stakeholders, the go-live plan is initiated and the specific steps for go-live are executed by resources defined in the plan. Once the application is in production, and post-production testing indicates a successful deployment, send a communication to stakeholders and end users to notify them. In the event that there are any issues in production, clearly explain what they are and the plan to fix them.
Published May 8, 2018 — Updated January 11, 2019