This is a brief

Anchor
SupportProcess SupportProcess

DSD-Marine Support Process

This is an overview of the support process used by DSD-Marine (a.k.a. AFCCB or MARINESAFETY), from SMGS ticket to TFS and back againtriage and support process.  Please review this process to familiarize yourself with how to properly manage application support for our MSS applicationsthe Marine Safety and Security (MSS) application portfolio.If you have any questions or concerns, your Scrum Master can provide additional information or guidance.Note: If you are receiving e-mails or phone calls from business clients seeking application support, please let your Scrum Master know as soon as possible.  While we are committed to provided timely support to our clients, we want to minimize any additional impact on your Ninja Team's sprint velocities. Clients will be advised to contact the Transport Canada Service Desk for all application support needs.  Please contact me (justin.green@tc.gc.ca) if you'd like samples of the e-mails that I've sent to clients in an attempt to better explain the situation.

Anchor
SMGS SMGS

Service Manager (SMGS)

The Service Manager (SMGS) can be reached at http://smgs:30201/sm/index.do.  To login to the system, use your TC userid and password.

If you are unable to login to SMGS, please contact your scrum master.

Anchor
NewSMGS NewSMGS

Support: New SMGS Ticket - List

• Assigned field will be blank
• Status will be Open

Anchor
NewSMGSDetails NewSMGSDetails

Support: New SMGS Ticket - Details

• Status is Open
• Assignee is blank
• Reference number is blank

 Image Modified

Anchor
NewSMGSReferred NewSMGSReferred

Support:

...

SMGS Ticket Referred

• Status is “Referred”
• Assignee is set to Scrum Master of related Primary Developer (see wiki for list of scrum team associated with the Service - see Second-Level Support (list on https://tcmarin.atlassian.net/wiki/spaces/MAR/overview) page.
• Reference Number is set to the associated TFS DevOps ticket number (see Support: New TFS New DevOps Ticket)
• TFS DevOps ticket number, enclosed by brackets, is appended to the end of the SMGS ticket’s Title field

Image RemovedImage Added

Anchor

...

NewDevOps

...

NewDevOps

Support: New

...

DevOps Ticket

• Title follows the format: <English App Acronym> - <IM Number> - <SMGS ticket Title>
• TFS DevOps ticket is Unassigned
• One tag created and set to <English App Acronym> (e.g. CPSCS).
• Second tag created and set to “TRIAGE” TRIAGE.
• State is set to “New” (default).
• Area is set to the appropriate Work Area within the “Marine Safety “MSS Portfolio” project. The Area selected should match the application/system identified in the title.
• Iteration Path is set to Ninja Team related to the Assignee entered in Support: Triaged SMGS Ticketchanged to "MSS-Portfolio".  
• Repro Steps is set to the Description as seen in Support: New SMGS Ticket Details
• If there are any attachments in the associated SMGS ticket, they are attached to the TFS DevOps ticket via the Attachments tab (not shown).
• If there are any additional materials related to this issue (i.e. e-mails sent to ninja teams or scrum masters team to further clarify the reported bug), they are attached to the TFS DevOps ticket via the Attachments tab (not shown).

Image Removed

Support: Triaged TFS Ticket (DATA)

• State is Approved

Image Added

Anchor
SupportTriage SupportTriage

Support Triage

It is important that TRIAGE tickets in DevOps are reviewed regularly by all DSD-Marine scrum teams.  Marine Safety and Security stakeholders have access to dashboards showing the current state of MSS Application support by DSD-Marine.  Large numbers of tickets waiting for triage may give MSS stakeholders a negative impression of DSD-Marine's current efforts to support the MSS application portfolio.  Please take the time to triage tickets every day.

Anchor
DataTriage DataTriage

Support: DATA Triage

• State is New
• TRIAGE tag is replaced with DATA tag
• Optional: Discussion note added to further clarify the current state of the ticket.

Image Removed

Support: Triaged TFS Ticket (CODE)

• State is Approved
• TRIAGE tag is replaced with CODE tag (see Fig. 1 below)
• Iteration Path is changed to "Marine Safety Portfolio".  Other Ninja Teams may be assigned to work on this CODE ticket: changing the iteration path will make this ticket more easily visible to the other teams.
• Effort field records any time (in hours) spent determining that this ticket will need a code change to fix.
• Discussion note added with the following text: "Triage performed by <name>" where <name> is your name.
• Assigned To field is cleared (unassigned).
• This bug will now get addressed as part of a future sprint for the system/application named in the Area field. Follow the development and TFS procedures as defined by the SCRUM process and by your scrum master.
• Ticket . DATA bug fixes can be handled without the need for application code updates and/or releases to TC's production environment.   These fixes generally involved database manipulation or client instruction to correct or workaround the reported bug.
• Iteration changed to match the default Iteration of the scrum team that triaged the bug ticket (e.g. "MSS-Portfolio\Team Kraken")
• ConversationID is set to the name of the Scrum Team that triaged the Bug:
  • KRAKEN
  • NARWHALS
  • TURTLES
• Ticket can be added to current or future sprint backlogs where effort and acceptance criteria will be established by the scrum team and business/product owner for the identified application
• Discussion notes, attachments, and links to related tickets should be used to further clarify the issue.

Image Added

Anchor
UrgentDataTriage UrgentDataTriage

Support: URGENT DATA Triage

• State is New
• TRIAGE tag is replaced with DATA tag. DATA bug fixes can be handled without the need for application code updates and/or releases to TC's production environment.   These fixes generally involved database manipulation or client instruction to correct or workaround the reported bug.
• URGENT tag is added to the ticket. Client has identified a bug as urgently requiring a fix: these fixes should be resolved within 1-2 business days due to the potential for severe impact on clients and/or the external stakeholders without the possibility of workarounds.
• Iteration changed to match the default Iteration of the scrum team that triaged the bug ticket (e.g. "MSS-Portfolio\Team Kraken")
• ConversationID is set to the name of the Scrum Team that triaged the Bug:
  • KRAKEN
  • NARWHALS
  • TURTLES
• Ticket can be added to current or future sprint backlogs where effort and acceptance criteria will be established by the scrum team and business/product owner for the identified application
• Discussion notes, attachments, and links to related tickets should be used to further clarify the issue.

Image Added

Anchor
ReportTriage ReportTriage

Support: REPORT Triage

• State is New
• TRIAGE tag is replaced with REPORT tag. The Business Intelligence (BI) team should be involved with all REPORT requests.  The BI team may have a solution in place for use by the stakeholder requesting the report. Alternatively, we may be able to work with the BI team to make sure that similar report requests in the future can be handled via a BI solution.  BI team can be contacted at DL OTT Information Management DMI (cc Jeff Annable).
• ConversationID is set to the name of the Scrum Team that triaged the Bug:
  • KRAKEN
  • NARWHALS
  • TURTLES
• Discussion notes, attachments, and links to related tickets should be used to further clarify the report requirements.

Image Added

Anchor
UrgentReportTriage UrgentReportTriage

Support: URGENT REPORT Triage

• State is New
• TRIAGE tag is replaced with REPORT tag. The Business Intelligence (BI) team should be involved with all REPORT requests.  The BI team may have a solution in place for use by the stakeholder requesting the report. Alternatively, we may be able to work with the BI team to make sure that similar report requests in the future can be handled via a BI solution.  BI team can be contacted at DL OTT Information Management DMI but the urgent nature of this request will require a more immediate hands-on approach unless BI has an existing solution.
• URGENT tag is added to the ticket. Client has identified the report as urgent (i.e. upper management or Minister's office request). These reports will be needed ASAP: refer to the Repro Steps information or attachments for further information.  
• ConversationID is set to the name of the Scrum Team that triaged the Bug:
  • KRAKEN
  • NARWHALS
  • TURTLES
• Discussion notes, attachments, and links to related tickets should be used to further clarify the report requirements.

Image Added

Anchor
CodeTriage CodeTriage

Support: CODE Triage

...

• State is New
• TRIAGE tag is replaced with CODE tag (see Fig. 1 below)
• Iteration Path remains unchanged.  This CODE fix may be added to any scrum team's sprint backlog based on MSS priority and team capacities.
• ConversationID is set to the name of the Scrum Team that triaged the Bug (ConversationID will be changed if another team fixes this bug):
  • KRAKEN
  • NARWHALS
  • TURTLES
• Ticket can be added to current or future sprint backlogs where effort and acceptance criteria will be established by the scrum team and business/product owner for the identified application.  
• If this bug is preventing clients from using the application/system and/or if the client has identified this fix as urgently required, add the URGENT tag procedure to initiate an emergency release should be followed. Contact your team lead/scrum master for further detail.
• Discussion note added with the following text: "Triaged and SMGS ticket closed."
• Ticket is closed in SMGS (see Fig. 2 below) should be closed and a .  A note must be added to the SMGS ticket's Solution text that reads: "Issue being tracked in TFSin DevOps: <link>. Issue will be fixed in a future release." where <link> will direct client to the triaged TFS ticket.
• If this bug is preventing clients from using the application/system, procedure to initiate an emergency release should be followed. Contact your team lead/scrum master for further detail.

Image Removed

• DevOps ticket.  

Image Added
Figure 1: DevOps CODE ticket is triaged

Image Added
Fig. 2: SMGS ticket closed following CODE ticket triage

Anchor
CodeTriage CodeTriage

Support: URGENT CODE Triage

• TRIAGE tag is replaced with CODE tag (see Fig. 1 below)
• URGENT tag is added to the ticket.  The first step to is to confirm that this issue is urgent: if so, an URGENT CODE fix must be remedied immediately.  Scrum Team and Product Owners should be contacted to have the issue and effort assessed and placed on the current Sprint Backlog.
• Appropriate Acceptance criteria are determined by the product owners and scrum team.
• Iteration Path is changed to the responsible Scrum team's current Sprint iteration after the team and product owners have assessed the issue and effort has been estimated.
• ConversationID is set to the name of the Scrum Team that triaged the Bug:
  • KRAKEN
  • NARWHALS
  • TURTLES
• State is Committed.
• If this bug fix is an emergency (e.g. production site is down, data is being corrupted, etc.), scrum master or team should being emergency release procedure.
• Discussion note added with the following text: "Triaged and SMGS ticket closed."
• Ticket is closed in SMGS (see Fig. 2 below).  A note must be added to the SMGS ticket's Solution text that reads: "Issue being tracked in DevOps: <link>. Issue will be fixed in a future release." where <link> will direct client to the triaged DevOps ticket.  

Image Added
Figure 1: DevOps URGENT CODE ticket is triaged

Fig. 2: Closed SMGS ticket for triaged ticketclosed following URGENT CODE ticket triage

Anchor
SupportEffortResolution SupportEffortResolution

Support Effort and Resolution

Anchor
TrackingEffort TrackingEffort

Support:

...

Tracking Effort

• State is Committed.
• Effort for all bug fixes - DATA, CODE, or REPORT - should be recorded in the Bug's Effort field using the Fibonacci number. 
• Unlike standard bugs or PBI's committed during the refinement or planning scrum events, any estimated Effort should be updated with the actual effort once work is finished.  We would like to determine the actual percentage of effort is spent support stakeholder bug requests/tickets by DSD-Marine's scrum teams. 
• If there are two or more people working on a single DATA fixbug, please refer be sure to the Support: Pair Programming and Cross-Training for extra steps needed to track support time.

Image Removed

Support: Pair Programming and Cross-Training

• Create a duplicate of the committed DATA ticket (from Support: Working on DATA Fix)
• State to Committed
• One tag created and set to <English App Acronym> (e.g. PCOCDS).
• Second tag created and set to “XTRAIN”
• Remove any other tags
• Set "Assigned To" field to match the name of the second developer working on the DATA fix
• Record Effort for this ticket separately from the original DATA ticket: this will allow us to track the actual support time spent on a single ticket.
• Verify that the Links tab shows the original DATA ticket as Related

Image RemovedImage Removed

Image Removed

Image Removed

Support: TFS DATA Issue Fixed

• State is Committed
• “FIXED” tag added to the ticket. This tag will help your Scrum Master identify a fix as being completed (in case you are not able to close the related SMGS ticket yourself).
• Effort (in hours) has been updated to include the time spent fixing the bug.
• Acceptance criteria includes details of what was fixed and how the fix was applied to the application.
• A discussion note is added to provide further instruction to your Scrum Master (if needed in special circumstances).

Image Removed

...

• update the Effort accordingly.  Child tasks can also be created to help coordinate the fix across the development team.

Image Added

Anchor
BugResolved BugResolved

Support: Bug Resolved

• State is Done.
• Effort (i.e. Fibonacci number) reflects the actual effort spent by the the scrum team to resolve the issue.
• Acceptance criteria and definition of done have been met by the team.
• ConversationID is set to the name of the Scrum Team that resolved the Bug:
  • KRAKEN
  • NARWHALS
  • TURTLES
• All notes, correspondence and details of the work performed are recorded directly in the DevOps bug ticket and via any attachments to the ticket.
• A brief discussion of this issue and a link to the bug ticket are placed in an appropriate section in Confluence. Each MSS application has a page in Confluence that includes a section devoted recording common support issues and how these issues were resolved. See CPSCS-SCEPC page's "How-To and Fixes" section for examples.
• In the Discussion, add the following note: "Details of this ticket discussed and linked in <link>", where <link> is the MSS application's Confluence page (e.g. CPSCS-SCEPC).

Image Added

Anchor
CloseSMGS CloseSMGS

Support: Close SMGS Ticket

• Ticket Status is set to Resolved (not shown).
• Close button is has been clicked (setting Status to Closed).
• Appropriate Closure Code has been selected. "Solved by Action on Software" is a good one to use for many of the bugs we handle but there are many other valid options.  Discuss with your scrum master when in doubt.
• A brief description of the solution has been entered into the Solution field.  For example, "Issue fixed via database update. Client confirmed fix.

Image Removed

Support: TFS DATA Issue Closed

• State is Done.
• Related SMGS ticket has also been closed.

...

• " or "Report generated and sent to client via BI platform."

Image Added

Anchor
RecurringSupport RecurringSupport

Identify and Eliminate Recurring DATA Support

Every effort should be made to identify and eliminate recurring DATA tickets.  If you or your teammates find yourselves constantly resolving the same bugs for an application, it may be best to identify the root cause of the issue and take steps to fix the issue permanently.  To handle cases such as these, please refer the following suggested course of action:

1. Prior to Sprint Planning, refer to master priority list for bugs to identify the highest priority MSS applications (see MSS Portfolio Bugs by Business Value list on the DSD-Marine: Support Overview page). This is a list of active bugs sorted by the MSS-assigned business value.
2. Take the application/area highest on the list being handled by your scrum team as shown on the Second-Level Support on the DSD-Marine: Overview page).
3. Review the applications's backlog, including open and closed tickets, to identify groups of bugs with high re-occurrence rates.
4. For each group of bugs, create a new single Bug ticket:
   1. Add the CODE tag to the Bug (since development work will be needed to resolve)
   2. Add the RBF (Recurring Bugs Fix) tag to the Bug - this will allow us to track fixes made to eliminate recurring bug tickets as suggested by DSD-Marine.
   3. Add the application tag to the Bug  (e.g. CPSCS, SVCP, SRCS, etc.). 
   4. Set the Bug's Area to match that of the grouped recurring bugs
   5. Link all of the related bugs (as Related) to the Bug. This will allow the development team to review all of the past, present and future Bug tickets that have been created related to the CODE fix.
   6. Fill out the Repro Steps for the Bug with enough detail to describe the issue and allow for the development team to reproduce.
   7. Add an estimated Effort to fix the Bug permanently.
   8. Iteration should be set to your scrum team's base iteration (MSS-Portfolio/<Team Name>).
5. Repeat Step 4 for as many groupings of bugs as needed.  It may be best to address a handful of CODE fixes to an application at once to optimize the cost of planning and releasing new code to product.
6. Set up a meeting with the dev team and all product owners for your current project and those related to the recurring Bug(s) created. For each of the recurring Bugs identified:
   1. Show the product owners the cost (in Effort) that is being spent repeatedly fixing the same DATA fixes.
   2. Define Acceptance Criteria for the Bug.
   3. Have the Product Owner(s) assign a business value to the Bug.
   4. Set the State to Approved.  The product owners will need to prioritize this bug for a future sprint so that it can be committed to a sprint backlog by the development team. 
7. ConversationID is set to the name of the Scrum Team that will resolve the RBF bug:
   • KRAKEN
   • NARWHALS
   • TURTLES

Image Added

By following this process (or whatever similar process works best for you team), DSD-Marine can move beyond quick fixes that ultimately do nothing to reduce the steady flow of SMGS bug tickets.  

While every team should attempt to limit support to 1.5 hours per day per development team member, there may be cases where a little more time spent on a fix for recurring DATA bugs could save everyone a lot of time down the road. Scrum teams and product owners must work to identify long-term bug fixes that deliver the most business value and will have the greatest positive impact on DSD-Marine's capacity to handle application development, support, and maintenance.

Anchor
AdditionalSupport AdditionalSupport

Appendix I: Additional Support Procedures

Anchor
ClientCalls ClientCalls

Handling Support Calls and E-mails

If you are receive e-mails or phone calls from business clients seeking application support, please let your Scrum Master know as soon as possible.  While we are committed to providing timely support to our clients, we want to minimize any additional impact on our scrum teams' sprints.  Clients should be directed to use the DSD-Marine Support Intake Form to request support for system/applications bugs and enhancements.    

Anchor
AccessRequests AccessRequests

Handling Application/Network Access Requests

From time to time, you may come across an SMGS ticket requesting system or application access for a new user. If you happen to see an SMGS ticket (change, IMAC, IM) asking us to grant user access to a MSS application, please re-assign the ticket from MARINESAFETY to “ACCESS CONTROL – NCR”.

We’re not authorized to grant users access to applications and this responsibility belongs to our clients. ACCESS CONTROL will make sure that our client admins see these requests. If you have any outstanding tickets in SMGS related to this matter, please re-assign them as soon as possible (and close any related DevOps tickets).  

EXCEPTION: We do handle all MSDQT access requests. Create a ticket in DevOps and assign to the appropriate Second-Level Support team (found on the Marine Overview page).

Appendix II: Application Support Resources

Anchor
SupportDashboards SupportDashboards

DSD-Marine Support Dashboards

The following dashboards/reports have been created to give MSS stakeholders and the DSD-Marine team information about the current state of application development, support, and maintenance of the Marine Safety and Security application portfolio.

• DSD-Marine: Support Overview: Overview of DSD-Marine's support of the Marine Safety and Security Application Portfolio
• DSD-Marine: Support Effort: Overview of the impact of support & maintenance of the MSS application portfolio on DSD-Marine Scrum Teams.

Anchor
SupportIntake SupportIntake

DSD-Marine Support Intake Form

The DSD-Marine Support Intake Form can be found in RDIMS:

• DSD-Marine Intake Form - English (RDIMS #15574117)
• DSD-Marine Intake Form - French (RDIMS #15574125)