Delivery Team Processes


Support for Delivery is in a state of transition. In in doubt about the process, please do ask in #delivery.

The following is true as of .

Requesting our support

Feel free to direct simple questions to us in #delivery in Slack.

  • This channel is regularly checked and well monitored
  • 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 and we’ll ensure it gets the best response

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/delivery is added to the issue
  3. Ensure that the issue is added to the ”Delivery” board in GitHub
  4. Anything without a status is checked and triaged weekly - so this is enough for feature requests or less urgent issues
  5. If you think this needs eyes 👀 sooner
    • Within a few hours ➡️ message in #delivery
    • ASAP ➡️ message in #delivery and CC @delivery-support

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