Planning: March 21, 2022

March 21, 2022

Agenda

v3 Overview

• Introduce WiKi
  • Why WiKi?
• Discuss Process
  • What problems are we trying to address?
  • What behaviors are we attempting to encourage?
• Introduce Kanban board
  • What are some best practices?
• Discuss cadence of Meetings
• Where do we hope this can become?
• How can we make this better?

Week 1 Planning

• Align on priorities for the week
• Present Issues in Ready
• Break down tasks and create new Issues if necessary
• Provide rough estimates
• Commit to Issues

Notes

• Visualization
• Prioritization
• Communication
• Documentation

This is about communication around software development.

We need comments on issues to improve documentation and understand why decisions were made. The back and forth can continue happening on Discord but we want to make sure the decisions are captured in Issue comments.

We need to be aware that right now we are doing the weird work that is somewhat difficult to track and test.

We are managing multiple projects and processes on the same board. Eventually each project has it's own board and each column has it's own process.

Things are going to get stuck. Frustrations will emerge. If we are honest and communicated our problems and needs we can continue to make the system better. This is a coordination game. Our goal is to move issues to Done. It does not have to be fast. It should be consistent and reliable.

The more we standardize our system the easier it is to automate and abstract.

We can improve coordination and make this fun. We can add metadata and make it composable.

This is just the seed. We have to shape it, question it and improve it.

We are building a machine together.

Behaviors

• You pull the work
• Limit work in progress
• Capture decisions in comments on Issues
• Push to Done
• Highlight blockers and swarm to resolve
• Make improvements as a team

Comments and Notes (jp)

• One thing to be mindful of is increasing the size of our Kanban board
  • Given a goal is to break cards into single items where possible and we want to avoid having too many items in each lane, we may soon encounter a crowded board
  • As we identify and solidify best practices we can replicate these across other GitHub project boards. For example:
    • It may make sense to split into a Rage Board and a Sage Board as these grow -- they're already separate repos, but we're tracking issues and cards in a single project board
    • As projects emerge and evolve can share learnings and copy processes as a starting point (and then the project team can iterate)
• Items that are in the Ready lane should represent a level of collective knowledge and fidelity -- these cards should include enough context, detail, and resources so that folks are able to self assign and work without needing to ask additional questions
  • Dragon team responsible for ensuring that these cards are in appropriate state of fidelity (labels, context, resources such as Figma, etc.)
• Need to split out certain cards that are too big in scope (monorepo CI/CD and DevOps)
  • In progress -- this card can be archived once it's all represented
• Cards won't be directly assigned to folks -- each week in the Monday planning meeting people can grab what they want to work on and move into the Development/Design lanes from Ready
• Balance between the team assessing and identifying prioritized work and being able to self-assess:
  • Goal is to communicate and be as transparent as possible -- we're aiming for a balance and middle ground here

Component Library and Design Ops Processes

• We need to add additional cards to represent the work being done toward this by Andy and Jord
  • Currently they're building out the Rage Summoner App and adding components to the Rage component library package as they go
  • We've identified and aligned around Radix and Stitches, so we should refine the current cards to represent this
  • Adding Storybook to this makes sense as a next step so that Andy and Jord can begin experimenting and building familarity around processes for adding stories
  • In parallel we can build the Sage component library package (DevOps around creating the package, adding Storybook, and deploying)
    • This can happen at the same time and is no longer a blocker since Andy and Jord can work in a Rage Storybook
    • Note: Deprioritizing the Ladle exploration since any benefits in build speed may be lost in not having tooling support
• We should create a separate Component Library GitHub Project Board and represent the workflows there
  • We can take steps for this to not become a silo'd process, and this will allow for more granularity and review between design and dev teams
  • We'll take some time this week to experiment with a v1 for this

Todo

• Break out issues for Monorepo CI Setup
• Add tag/milestone for week-1
• Explore creating a component specific project board
• Add issue for Storybook tutorial
• Add issue for Redux tutorial
• Break out Sage monorepo DevOps/CI tasks into separate cards
• Add additional component library cards to more accurately represent the work being done this week
• Brainstorm/test Storybook and Design Ops/Processes in the Rage component library