Don't panic! Sometimes things do go wrong. It's important that these issues are fixed promptly, without compromising on quality. The process below will help guide you through how to identify whether an issue should be deemed 'expedited', and importantly how to proceed with providing a fix.
Confirm with a metric such as:
- Bugsnags being generated
- Support service reporting issues
- Error screen showing raised errors
All issues must be routed to the senior most person responsible for taking action for the specific issue. Bypassing this person will greatly increase the complexity of resolving the task you are reporting.
Bypassing the chain of command also means you are possibly jeopardizing existing expedited issues by adding confusion and delays to the individuals tasked with resolving emergencies.
The senior most person responsible for taking control of this possible issue will need to work directly with the product owner to determine what metrics are being affected, eg:
- Conversion
- Customer Experience
- Revenue
As well as lifespan of the issue. If it is indeed an issue that needs to be expedited, the management involved should immediatley:
- Create a detailed Sprintly ticket
- Provide steps to duplicate
- Provide classification of issue and how it is affecting the company
Once a Sprintly ticket is created, a cross functional team should be created with the following elements:
- Designers to assist fix
- Developers to assist fix
- Developers to be available to review code promptly
- Tester(s)
- Product owner
Generally:
- Code developed using our best practices and procedures covered in the Doing Coding Culture.
Do we need to break any of the above, if so why?
- Speed of fix
- Complexity of fix
- Lack of resources (e.g. out of hours, no-one in office)
- Temporary fix (with permanent fix following later)
Do not use the reasons above as a get out clause to not follow processes. Going against the process will need to be discussed at the time and justified later in your communication about the issue to the team. If it is decided to move forward without following protocol, technical debt will be created and time will be budgeted to bring the temporary fix to company standards after emergency fix is deployed.
- Code deployed in the usual manner, to allow for rollback if needed.
- Monitor original problem metric to ensure fix is successful.
- Summary email to team (Include any revelant PR's / Sprintly Ticket's / links).
- Communication to origin of report; support center or other department.