Dev Team Process

Ward Sandler
Ward Sandler
Last updated 

๐ŸŽฏ Objective

Create an environment where the Dev Team can consistently get issues resolved and new features shipped via our framing, shaping, and cycle process while regularly communicating their progress and blockers.


โ˜€๏ธ Daily Workflow

  • Every morning - please look over any pending PR reviews first thing when you start working so we're not blocking code getting into Staging or Production.
  • Regardless of whether we're in a cycle or cool down, we meet as a team every Monday and Wednesday to discuss any blockers/questions and review the Dev Tasks board. During a cycle we'll have very few tasks to work on since the team should be primarily focused on cycle work (which lives outside of the task board).
    • Generally all new non-cycle tasks should be listed on the Dev Tasks board in the Backlog. During DT meetings you (or someone else) can advocate for working on a task over other tasks that could be worked on.
      • If you need to handle a minor improvement / chore / update autonomously that will take 1/2 day or less, you don't need to wait for a DT meeting. You should still create the task card though if the work is something other people in the company need to know about.
      • If the task is purely technical (i.e. the whole company doesn't need to know) add [Tech] at the beginning of the task's title.
    • When reviewing the task board we'll look at the ๐Ÿ’ก Backlog to see if the team has capacity. If so, we'll assign someone to the task and move it to ๐Ÿ Up Next which is a running list of tasks we're planning to accomplish over the next week or so. 
    • When you start working on a task move it to ๐Ÿง‘โ€๐Ÿ’ป In Progress.
    • Once you merge a PR for the task into Staging, move the task to ๐ŸŽ‰ FYI Done so the rest of the company is notified about this change.

๐Ÿšจ Issues

  • When Support notices an issue/bug, they will add it to the ๐Ÿ’ก Backlog and assign it an urgency:
    • [low] (we'll fix to it one day, it can wait indefinitely)
    • [high] (we should get to it within a few business days)
    • [critical] (we should stop everything and fix this, all hands on deck)
  • DT should regularly scan the ๐Ÿ’ก Backlog for new issues that pop up and then sort them into either the ๐Ÿšจ [FE] Issues or ๐Ÿšจ [BE] Issues column and from there they follow the same flow as other tasks described above.
  • Issues are the exception to the rule in that you can start working on them without first having a DT discussion.

โคด๏ธ Pull Requests

  • Request a PR review from msupdatebot โ€“ this will automatically trigger a ping in the Development Team campfire to get reviews from the team.
  • If you want Support Team to QA test something, after you've moved the task to ๐ŸŽ‰ FYI Done ping "@support" in the task comments asking them to test it in a Staging site. Generally you should be testing your changes in a Staging site first though.
  • When you're ready, merge Staging into Production. Do not merge into Production after 2pm ET or on Fridays at all unless it's an urgent fix.
  • You should be submitting a PR every 1-2 days even if you're work is still in progress. The point is to get in the habit of pushing small chunks of work instead of waiting for every part of the task to be completed and to start getting feedback from other team members.