DevProcess.md

General Principles

• Set goals for the team to pursue and align around.
• One focus per quarter - either a product area or theme; constrains build efforts.
• Mostly defined Projects.
• Leave space for smaller items that add a lot of value.
• Projects should take 1-3 weeks to build with teams of 2-3 people.
• Build in 2-week Cycles - task density should feel reasonable.
• Break work into smaller parts when possible - to track / see progress.
• Every Feature / Project / Design Doc / Task has a single named owner, and the owner is responsible for the ultimate delivery.
• Increase velocity.
• Decide and move on - sometimes there isn’t a clear answer.
• Take swift action - Speed is everything. Startups die when they move too slowly or don’t see progress and give up.
• Call out analysis paralysis whenever you see it.
• If a decision is reversible (2-way door), just make it; we can always reverse it later.
• Everything we do is tracked in Linear or Notion.

Meetings

Monday Kickoff

• 1 hour, weekly.

Sprint Planning

• Alternates with Team Update meetings.

Prior to Sprint Planning

• Task owner to update:
  • Task status for any task In Progress.
  • Level of Effort.
  • Dependencies.
• Project Owner to update:
  • Backlog (grooming).

Team Update

• Alternates with Sprint Planning meetings.

Standups

• 15 min, daily.
• Discussion:
  • Did Yesterday - last 24h prior standup.
  • Doing Today - next 24h until next standup.
  • Blocked / Need Input.
• Be proactive about tagging blockers and @mentioning who should own the response.
• Any notes to share with the whole team.
• Review tasks “In Review” - SLA of no more than 5 tasks in review per reviewer.

Backlog Grooming

• Ad hoc.
• All tickets in Backlog: flesh out details, review implementation plan with team, add LOE.

Retro

• 1 hour, monthly.
• Why: To continually hone our process as a team.
• Call out actions / behaviors that change; poor decisions.
• Format: same as before - constructive conflict.
• What:
  • Document lessons learned, challenges faced, and solutions implemented.
  • Review metrics.

Design

• 1 hour, 2x/week.
• What: design / architecture of protocol and backend.

Documentation

• Features (PRDs)
  • Stored in: Notion → 🛣️ Features.
  • Written by: Product Owner.
  • Proposed by: anybody.
  • Definition of Done:
    • All requirements clearly listed in bullet format (for easy reference).
    • Reviewed by: Project Owner.
    • Reviewed by: Project Build Team.

Projects (Implementation of a PRD)

• Stored in: Linear → Projects.
• Owned by: Project Owner.
• A single individual responsible for the delivery of the Project and maintenance of the project’s backlog.
• The buck stops here.
• Built by: a team of 2-3 people.
• Definition of Done:
  • Integration / E2E tests that target coverage of 100% of PRD requirements.
  • Proactively call out any requirement that is not covered by tests with a comment in the PRD, along with rationale for why it was not covered.
  • All tasks done (or marked for future iteration).
  • Reviewed by: Product Owner.

Design Docs (Specs)

• Stored in: Notion → 📐 Documentation using TEMPLATE.
• Store relevant data in Notion ← better search than Linear.
• Purpose:
  • Overview of contract goals, why decisions were made, logic that is deployed, state that is used, any dependencies; holistic representation of how everything hooks together - interfaces / API spec.
• Goal: somebody should be able to look at the design doc and write the contract.
• One Design Doc per contract (when necessary).
• Overview of what a contract does (TEMPLATE).
• A single Feature may impact multiple Design Docs; in this case, all required Design Docs would be updated.
• Open Q: how do we track DD changes for PRDs that change multiple contracts?
• Owned by: Project Owner.
• Written by: Project Owner + Build Team.
• Definition of Done:
  • Proactively call out any changes from the PRD, along with rationale for why.
  • Reviewed by: Product Owner.
  • Reviewed by: Build Team.

Tasks

• Stored in: Linear → Active Tasks.
• Written by: Build Team.
• Tickets should cover all work that is being done, so that we can understand our velocity and where we spend our time.
• Owned by: Individual executing engineer.
• Must include:
  • Link to Github PR (where applicable).
  • Acceptance Criteria.
  • Link to the PRD requirements that are being built (where applicable).
• Definition of Done:
  • Testing: At least one unit / integration / E2E test (if necessary).
  • Written by the engineer who writes the code - up to engineer’s discretion as to type of test to write.
  • In the PR.
  • Documentation: Design Doc edited / PRD commented to indicate where decisions made while building deviated from plan.
  • If we use Github for DDs, then every PR should include updates to the DDs as well.
  • Code Review: Code is reviewed and approved by one person who is not the owner.
  • Owner sets the Reviewer using the “Reviewer: …” label.
  • Bugs: whoever opened a bug needs to be the one who reviews / closes it.

General guidelines

• When writing a task for somebody else, frame it as an ask / describe the problem. Then the owner of the task will rewrite it as a task.
• Slack
  • Turn on notifications for #core-eng and generally other channels where you are @mentioned.
  • Expectation of response of some sort (including just “ack”) within 2 hours during your working hours.