- Keep it simple: maximize productivity and reduce waste.
- Small, iterative changes: we move more quickly and reduce risk.
- Quality over quantity: ship 1 issue well rather than ship 2 poorly.
- Be proactive: bias toward action to keep the team productive and shipping.
- Deploy often.
- Simple, well written and readable code.
Working asynchronously also means you don’t need to wait for other people to assign you work. There will always be a backlog of work and if there isn’t you should use your better judgment and pick up whatever you think has the most impact/benefit. If there isn’t any work planned you should bring it up with your manager, there should always be a plan.
As all work should be written down in issues, if you’re doing something out of your own volition and no one shared a spec (tech or product) with you, then create an issue for it before you get going.
Working async first also means:
- GitLab is the single source of truth. Discussions on Slack can be helpful, but async discussions in GitLab are better. At minimum, make sure takeaway from discussions always get reflected in GitLab.
- Issue descriptions should always be up to date. It's not efficient to need to read through a comment thread or Slack conversation to be fully up to date on what we need to accomplish in an issue.
We use Kanban (看板) (signboard or billboard in Japanese) to work. Think of it as pipeline process flowing from left to right, from concept to execution.
This workflow focuses on keeping things simple and nimble so when in doubt, take action and choose the simplest option.
We use GitLab for our development workflow:
- Each product team may have up to three GitLab boards:
- A product team board ("Product Flow" board) that shows the entire value stream at each stage of development. (i.e.: Foundation - Product)
- An engineering-specific product team board (i.e.: Foundation - Eng)
- A design-specific team board (i.e.: Foundation - Design)
- This board is the single source of truth on work that is being refined and is available for development. If someone is working on it, it needs an issue that's visible on the board.