What is the problem?
for dao
– not everyone on github, also very tied to dev work. specific language. hard to grok high level across the rest of the dao. Timing of features vs release vs in prod still a bit hazy for people.
for product/eng
: github tickets get overwhelming. The only reward for finishing work is …more work, a neverending slog of medium priority. really hard to timebox effort and generate momentum. no stats on how we're doing week on week. no sprints or breakdowns, and we could use a cadence.
- Most importantly, we have to bolt on other meetings, massaging what happens and disseminating that knowledge. There is a "default to conversations on PR's" without feedback/eyes from others. Have to repeat comments all the time.
- Discord silos PR's only.
What do you need to know about linear? and how is it a solution?
- use linear on top of github, instead of replacing it. two way sync is enabled for issues.
- This solves visibility, notifications, and personalized "views" of activity.
- Also Discord has a linear plugin for making issues, which is good if we set guardrails.
- PR management and review still happens on github.
- adding LIN to PR descriptions (or copy pasting the ticket from linear) updates statues for everyone which is pretty slick.
- Linear is an extra tool fine tuning collaboration, momentum, and alignment for the DAO (more than only a product/engineering tool).
- We will have to change our planning mindset into using Linear first.
- Solves for additional transparency.
what benefits do we get
- Time box of a cycle, tickets grouped by project, higher level milestones via project view (which is easier to understand), easier to kanban or view work in different ways. More functionality than github boards/tickets. Easier to use. Also, it's pretty.
- Project framing is easier to grok.
- We can also kick tickets to product and see their unblocking.
- notifications easier and more contextual.
- Comments and issues more cohesive and aligned with design/code iterations.
- Easier to highlight other teams input.
drawbacks?
- Kind of annoying to add
LIN
and the ticket name to PR's and tickets so they close.
- Sometimes issue sync isn't 100% perfect.
- It's another tool until comfortable with it's notification flow.
- We have to pay for seats over 250 tickets so if other teams start ticketing all their work it's messy.
what processes need to change?
The largest is just a mindset and cadence change, we'll change groooming => cycles (Cycles are sprints).
- Instead of weekly grooming we'll change into cycle planning week one, and cycle check in week two.
- With two eng syncs in between re-evaluating what's in progress and getting ticket numbers right (sizing, priority, timing, especially blockers).
- Tickets are aligned and championed at beginning of two week cycle.
- Tickets get rough priority, owner, and decent estimations at beginning. Leaving room for escalations, bugs, and anything else.
- Second week grooming is hard estimations and reconfiguring (so data is accurate).