Software Development

Advice Process for

This Advice Process document is a retrospective re-organizing using updated templates.

• Not all of the dates of the original Advice Processes have been preserved.

• The Process Documentation referenced are sourced from an original document that had everything in one place (see post-ratification notes on the rationale for breaking them up)

Original Proposer	Bomee	July 20, 2023
Revision Proposer	John Tunison / Reuben Firmin	Sept 27, 2023
Revision Proposer	Chuck	Nov. 20, 2023

Advice Stakeholders (AS)	Consent Stakeholders (CS)
Henry Baum (Intern)Minghan Zhu (Intern)Reuben FirminMarc Zuluaga	Jason BlockRobin NeriChuck LinMeghan CowartBomee Jung

	Asynch DeadlinesSummit review comments by	Meeting Date/TimeCS attendence requrested
Discovery
Debate
Decision		October 10, 2023

Problem statement

Formalize the feature request to tickets to released feature process to reduce friction (time/confusion) in the software development process

• Observed by John/Reuben that Chuck is spending a lot of time being merge-master that could be redirected to coding instead

• Observed by Bomee that work and tickets are not tightly bound - there are tickets that are not progressing and work being done that is not ticketed

Goals

TLDR

• Free up Chuck for coding

• Reduce low-return meeting time (e.g. time spent reporting status)

These outcomes are articulated not only so we know why we are following this process, but also because we can use them to evaluate whether the process is working well (—>resulting in the outcomes).

Outcomes Benefitting the Product Team

• We should prioritize features that make us money.

  • For example: Features tied to contract renewals or new sales can be prioritized above other features to ensure near term delivery.

  • Some features may require a sustained effort but we still have to prioritize them. Even when they are complex and require multiple pieces of work to be completed in order to achieve the outcome.

• There is unambiguous consensus on the order/priority in which things should be worked on

• We can set business expectations with users/customers because we know which features are targeted for delivery in the near future.

• Release packaging and feature grooming processes work like clockwork so that development work happens within the minimum of surprises

• Team uses clear shared vocabulary for feature/issue/release management

Engineering Process Goals

We will reflect on and update our processes on a regular basis through the retrospective cycle. We aim to adopt pragmatic processes, and generally to adhere processes to the following principles:

• Spend less time on bullshit tasks and more time on developing

• Aim for higher team output: this means a) that we want to optimize for delivery and b) that sometimes an individual’s code output is reduced in order to improve the team’s.

• Optimize for quality, and ship often and reliably

• Give developers/creators large blocks of uninterrupted time to work (http://www.paulgraham.com/makersschedule.html)

• Enough meetings, but not too many. Working meetings should be roughly 6-10 people at most.

Proposal

Adopt a revised Feature & Release Management Process (link borked) that includes

• Changes to recurring meetings

• Introduces design documents and ADRs

• Changes to git/release workflow

Context and Background

What information do stakeholders need to know to meaningfully participate?

Post-Ratification Notes & Lessons Learned

Experiment Start Date	October 10, 2023
Progress Evaluation Date	November 21, 2023
Experiment End Date (if any)	December 31, 2023

Nov 20 Revision to Process

• What went sideways:

• Unable to release major feature update for 6 weeks

• PRs were piling up causing frustration both in-house and at DevSquad

• High friction for testing – testing environment too slow

• More bugs in Prod being caught by users

• Chuck spending more time rather than less doing merges