Workflow Process

Ward Sandler
Ward Sandler
Last updated 

๐ŸŽฏ Objective

Create an environment where the Dev Team (DT) can consistently get new features shipped, customer issues resolved, and maintain a healthy codebase while regularly communicating their progress and blockers.


โ˜€๏ธ Daily Workflow

  • First thing everyday look over pending PR reviews (BE / FE) so we're not blocking code.
  • Meet as a team every Mon & Wed to review updates, blockers, and questions for Task board and cycle work.
  • All non-cycle work should be listed on the Task board in the Backlog.
    • During DT meetings, anyone can advocate for working on one task over another.
    • We should assess capacity before assigning tasks to anyone. After assigning, move task to In Progress
    • If a task is purely technical (i.e. the whole company doesn't need to know) add [tech] at the beginning of the title.
    • If you need to handle a minor improvement/chore autonomously that will take 1/2 day or less, no need to wait for DT meeting or create a task. Do create the task though if the work is something other people need to know about.
    • Once you merge a PR into Staging, move task to FYI Done so everyone is notified.

๐Ÿ”„ Cycle Workflow

This process is loosely inspired by Shape Up
  • First shaping work is done (research > discussions > lofi designs) which involves the LT + Nic and the DT as needed.
    • End result is a finalized Build Doc (example) with a time boundary (usually 6 weeks). 
    • Point of time boundary is to cut scope as needed while building, not add on more time.
    • Before cycle starts, DT will create initial scopes they're seeing (as FE & BE todo lists) and identify any potential time bombs which should be explored.
    • For each question that needs discussion, a message thread should be created
    • Hifi designs will be mostly finalized during shaping but there are always tweaks during a cycle and DT will be made aware of them. 
  • After cycle starts, DT will work on various scopes. Should do a rolling QA (as needed) with entire company as scopes get finished with goal of them going live asap.
    • During a cycle DT's priority should be the cycle, not tasks. However, occasionally DT will be interrupted to work on an important task. If needed, the time spent on those interruptions can be added back onto the cycle.
    • Each DT member should update their scopes on their respective Hill Chart every day during a cycle.
  • Before go live of any scope, everyone communicates to decide a date so comms work can be completed ahead of time (help docs, YouTube overview, announcements, etc).
  • Generally after a cycle we do 3 weeks of cool down to work on maintenance, bug fixes, and smaller UI UX enhancements.

๐Ÿšจ Issues

  • When someone notices an issue/bug, add a task to the [FE] or [BE] Issues list and assign an urgency:
    • [low] (we'll fix to it one day, it can wait indefinitely)
    • [high] (we should get to it within 5 business days)
    • [critical] (we should stop everything and fix this, all hands on deck)
  • If someone isn't sure if something is [FE] or [BE] feel free to ask Ward/Ryan
  • Issues are an exception where DT members can start working on them without waiting for the DT meeting. Just move the task to In Progress when starting.

โคด๏ธ Pull Requests

  • Request a PR review from msupdatebot to automatically ping the DT campfire for reviews.
    • When reviewing code, please follow our guidelines.
  • You should always personally test your changes in a Staging site.
  • When you're ready, merge Staging into Production. Do not merge into Production after 2pm ET or on Fridays at all (unless it's critical).
  • Should be submitting a PR every 1-2 days even if you're work is still in progress. 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.