Design Systems Team/Team Processes

"Continuous improvement is better than delayed perfection."

Kanban
Design Systems Team (DST) uses Kanban methodology.

Kanban is a scheduling system developed at Toyota with the aim of balancing demand and capacity, and limiting the amount of work in progress at the same time.

Estimation
Dedicate a portion of DST Planning meetings to estimate tasks chosen by the team:


 * Tasks in the “Up Next” column of our main workboard, starting with those marked high priority.


 * Technical Program Manager facilitates, using https://planningpokeronline.com to create a room for the team.
 * Engineering Manager, Product Manager, and Technical Program Manager should “Join as spectator.”
 * Task creator describes the task at a high level. Team has a chance to discuss/clarify.
 * Engineers & designers (depending on the task) select the number that correlates to their estimate of the task:
 * 1 point = Small. We feel we understand most requirements and consider it relatively easy. Most likely be completed within a day or two.
 * 3 points = Medium. We know what needs to be done, but there may be a few extra steps. Most likely completed within one week.
 * 5 points = Large. This is complex work, or work we don’t do very often. Will likely involve research or consultation. Most likely completed within two weeks.
 * 8 points = Extra Large. We need to break this down further (add to next Task Refinement agenda, or set up a separate meeting if urgent).
 * Once all estimators have estimated, the cards are revealed. Team discusses & aligns on an estimate.
 * Technical Program Manager adds the estimate to the Phabricator task, and moves the task into a logical column/board if needed.
 * Estimates may be updated at any time as the work progresses.

Work in progress (WIP) limits
Recommended background reading: https://www.atlassian.com/agile/kanban/wip-limits

Each column in the Design-Systems-Sprint board shall have either a defined WIP limit, or no WIP limit:


 * Committed: 30 points
 * Blocked: 30 points
 * Research: 15 points
 * Ready for Design: 15 points
 * In Design: 15 points
 * Design Review: 15 points
 * Ready for Development: 15 points
 * In Development: 15 points
 * Code Review: 15 points
 * Design Sign-Off: 15 points
 * QTE Sign-Off: 5 points
 * Product Sign-Off: no WIP limit
 * Pending Release: no WIP limit

Planning

 * Review/discuss tasks that have been prioritized by PM for the next two weeks
 * Achieve a shared understanding of the work
 * Estimate tasks, accounting for complexity, risk, and difficulty

Task Refinement

 * Focusing on tasks in the "Needs Refinement" column of Design-Systems-Team board:
 * Clarify requirements, acceptance criteria, dependencies for tasks within our top priority projects

Strategy

 * Discuss open questions around our product strategy and realign on the roadmap and OKRs.

Engineering Enclave

 * Discuss technical topics in-depth
 * Standing topics:
 * If we're going to swarm, let's coordinate our swarming
 * What needs to be included in the next release?
 * What should we do in our next live code review session?

Live Code Review

 * Engineers review a pre-selected patch or patches together

Standup

 * Bring questions & issues that would benefit from real-time discussion - particularly about design/engineering handoff & spec review

Design Sync

 * Discuss and align on topics related to the design of design tokens, components, patterns and guidelines

Office Hour

 * Discuss emergent topics related to team direction, strategy, and processes with product/engineering/design/program management
 * Surface questions/issues that need cross-functional support or decision-making between engineering, design, and product/program management

Team Processes Task Force

 * Ensure DST team processes are defined, socialized, and understood
 * Facilitate improvements to team processes, such as:
 * Choosing and adhering to an Agile framework (scrum, kanban, etc)
 * Phabricator boards & workflows
 * Meeting purposes & cadences

Tea Time

 * Enjoy some low-key social time together
 * Get to know each other better

Participants and roles

 * Design Systems Team Tech Lead: submit patches, review code and resolve disagreements, +2 patches
 * Design Systems Team engineers: submit patches, review code, +2 patches
 * Design Systems Team designers: conduct design review, may +2 design-related patches
 * Contributors outside the DST: submit patches, review code, +2 some patches (see below for details)

Conduct
We value code review not only as an opportunity to prevent issues and maintain a healthy code base, but as a process that encourages collaboration, knowledge sharing, and growth. We follow these guidelines for a healthy code review culture and ask that all of our collaborators do so.

Code review ratings
We follow the definitions of the code review ratings (-2, -1, 0, +1, and +2) as outlined in the general Code review docs. We have a few additional norms around these ratings:


 * -1 is a clear signal that changes are required before the change can be merged. Generally, we give the person who applied the -1 a chance to review again after changes have been submitted. If that person isn't available in a timely manner, or if it is very clear that the concerns were addressed, someone else can confirm that the issues were resolved and merge the patch.
 * 0 is used for general comments, questions, or non-blocking concerns. Only apply a -1 if there are blocking issues outlined in comments.
 * +1 is used liberally to show support for a patch that you do not want to merge for whatever reason. Multiple approvals of a patch offers encouragement and documents support for a code change.

Who can +2?
Most of the time, someone from the Design Systems Team will apply a +2 to merge a patch. That said, we welcome contributors from outside the team to +2 a patch if it's a minor or uncontroversial change, or if general approval of the patch has been demonstrated (e.g. via a +1 from a DST member).

Unresolved comments
We use unresolved comments as a signal that a patch is not yet ready to be merged. This is especially helpful when we want to get design review before merging a patch. Before you merge something, review the unresolved comments and determine if any are blocking. If not, the patch can be merged and unresolved comments can be addressed in a future patch.