Repo Management Processes

Support

Repo management handles our support without a rota - that is to say there is no dedicated engineer on support duties, instead work is picked up by anyone in the team.

Requesting our support

Simple questions guidelines:

Feel free to direct simple questions to us in #repo-management in Slack

  • This channel is regularly checked
  • So please do NOT directly message or CC an engineer - this is to try and protect their focus
  • Instead, if it’s urgent, please @ either the PM or the EM in the question in the channel

Support request guidelines:

Support requests related to our areas of ownership should follow this process:

  1. Make sure there is an issue - if there’s not, please create one and include:
    • A short description of the ask
    • A more detailed explanation of the background, the context and the challenge that needs solving
    • Any guidance related to the impact this is having
    • Any extra information that could help us solve or prioritize this
  2. Ensure lable team/repo-management is added to the issue
  3. Ensure that the issue is added to the ”Repo Management” board in GitHub
  4. This board is checked weekly - so this is enough for feature requests or less urgent issues
  5. If you think this needs eyes 👀 sooner, please message in #repo-management in Slack and CC the PM or the EM

Support request process:

  1. The issue lands on our Repo Management board
  2. It automatically appears with NO status - that indicates it needs triage
  3. The issue get triaged by the EM or PM - this can happen as a result of a frequent check or a message about a specific issue
  4. As part of triage, the EM or PM…
    1. Considers the impact or value to the customer(s) and our business
    2. Assesses the cost of the work
    3. Compares the cost and benefit to everything else
    4. Moves the issue to the correct column on the board
  5. Either immeadiate (as a result of triage) or at a later date, the issue is moved into “Todo”
  6. The team pick up issues from the Todo in a top down order
  7. The issue gets worked on

ℹ️ The team do not directly look at anything that’s not in the working columns on the board, and things only make it to those columns through triage by the EM or PM. Only the EM or PM will make the call to interupt in-progress work for an issue, with the exception of incidents.

How we work

We’re currently working in a Kanban style. It suits the fact that support work often cannot wait for a new sprint, and so the idea of being able to plan what we be delivered in any period of time is unreliable.

Kanban means we maintain a backlog of work we want to complete, prioritized in such a way that the team picks up the next highest priority thing.

This allows us to be flexible about what’s up next, but still protect the sanctity of concentration and focus, by avoiding (as much as we can) in-flight work from being dropped in favor of something else.

We still work in 2 week cycles, and have the following ceremonies:

  1. Planning (biweekly)
    • This is more of a “line up a queue of work in priority” exercise than it would be with sprints
    • By default, we make no time-based commitments, instead favouring a balance of strategic (long term) and tactical (short term repsonsive) work
    • This does not (and isn’t intended to) prevent newly identified work from superceding what gets “planned”
  2. Sync (biweekly)
    • This happens on the weeks we don’t have planning, and is a check in on the plans and anything new
  3. Retro (biweekly)
    • A review of what we did for learing purposes