diff --git a/0010-async-cloud-team.md b/0010-async-cloud-team.md new file mode 100644 index 0000000..83ec261 --- /dev/null +++ b/0010-async-cloud-team.md @@ -0,0 +1,92 @@ +# Asynchronous collaboration for the cloud team + +* Status: proposed + +* Deciders: @TANguyen1893 @mckornfield @emmanue @ZavenArra @peterwwillis @ximena9201 + +* Date: 2022-06-07 + +Technical Story: {description | ticket/issue URL} + +## Context and Problem Statement + +Engineering teams at Greenstand have typically incubated using weekly meetings and semi-synchronous communication in Slack. As team personnel, process, and technologies mature, the scope of individual tasks becomes smaller. Additionlly, conveying information primarily through synchronous meetings limits participation from those that cannot regularly attend, or are looking to contribute during unstructured time in their busy schedules. + +The cloud team has reached a point of maturity where adopting asynchronous processes can expand productivity, and needs to select the right suite of approaches to support team members in this effort. + +## Decision Drivers + +* Inclusion of engineers with varying availability +* Engagement and retainment of new contributors +* Productivity + +## Considered Options + +We will select a mix of options from the below list. + +1. ADRs for all proposed or accepted decisions +2. Manage small scope tickets via a cloud team github project board +3. Continue weekly meetings +4. Discontinue weekly meetings, and adopt a longer monthly meeting +5. Coworking times +6. Additional options / ideas? + + + +* {e.g., improvement of quality attribute satisfaction, follow-up decisions required, …} +* … + +### Negative Consequences + +* {e.g., compromising quality attribute, follow-up decisions required, …} +* … +--> + +## Pros and Cons of the Options + +### 1. ADRs for all proposed or accepted decisions + +Some decisions are made in meetings or through collective chat, others are proposals that need feedback. Regardless, all decisions must be written up as ADRs by the team members involved. Accepted ADRs can always be superceded by a follow up ADR. + +* Good, because this gives a clear record of all cloud thinking +* Good, because this allows groups of team members to act semi-autonomously to make decisions +* Bad, because it adds time and writing requirements + +### 2. Manage small scope tickets via a cloud team github project board + +Use the project board at https://github.com/orgs/Greenstand/projects/41 to track all work items with well defined, limited scope. These should be tasks that any contributor can pick up and complete with a few hours of work, assuming the necessary skills. + +* Good, because this gives a landing pad for contributors looking for work to be done +* Good, because this gives an asynchronous birds-eye view of progress on critical tasks +* Bad, because more project management time is involved +* Bad, because some larger scoped tasks might be tracked elsewhere + +### 3. Continue weekly meetings + +* Good, because this keeps the team coordinated and socially organized +* Good, because we are used to it +* Good, because new team members have a place to land +* Bad, because erratic attendence will continue, impacting productivity +* Bad, because an unstructured meeting is not always the most productive use of limited time + +### 4. Discontinue weekly meetings, and adopt a longer monthly meeting + +Instead of an _unstructured_ weekly meeting, organize a _structured_ monthly meeting - i.e. a meeting an agenda and agreed-upon attendance. + +* Good, because all team members can address large scope issues and updates together +* Good, because this provides sychronous meeting time to balance other asynchronous team process +* Bad, because there are more organizing requirements + +### 5. Coworking times + +Instead of weekly meetings, establish a cadence of working or hackmeet times + +* Good, because a lot could get done +* Bad, because of additional organization requirements +* Bad, because team members are not colocated +