Establish overall team processes

[carjug]

As a team, we would like to have a shared understanding for how we will collaborate, what our norms and practices are, and who fulfills/shares what roles.

Goals Establish how we will work together as a team (subject to iteration, as always)

Tasks

• [x] Set meeting cadences
• [x] Agree on relevant team-wide norms and preferences
• [x] If needed, further role clarification

[ninamak]

Meeting cadences proposal

Monday (Week A)

• 1-2pm ET / 10-11am PT: Sprint Demo (demo completed work and get feedback)
• 2-3pm ET / 11am-12pm PT: Break (add/update cards based on feedback, take a break, get lunch, go to eng mtgs)
• 3-4pm ET / 12-1pm PT: Project Health (discuss how project is going, which we will be more informed about post-Demo)
• 4-5pm ET / 1-2pm PT: Planning with Sheila (plan sprint's work, incorporate feedback from Demo as appropriate)

Monday (Week B)

• 1-2pm ET / 10-11am PT: Retro (reflect on team processes, dynamics, health, etc, and decide on experiments to improve)
• 2-3pm ET / 11am-12pm PT: Break (add/update cards based on feedback, take a break, get lunch, go to eng mtgs)
• 3-4pm ET / 12-1pm PT: Grooming (refine upcoming plans & priorities for project)
• 4-5pm ET / 1-2pm PT: Sync with Sheila (touch base, discuss updates, etc)

No meeting Fridays

Holds for possible co-works We don't need to use all these times, they'd just be blocked off on our calendars to make it easier to schedule if time is needed

• Tuesdays: 1-4pm ET / 10am-1pm PT
• Wednesdays: 12:30-1:30pm ET / 9:30-10:30am PT
• Thursdays: 1-3:30pm ET / 10am - 12:30pm PT

Questions for the team

1. I'd normally schedule Retro on Week A (marking the end of the sprint), but calendars make this difficult. How would you feel about rolling Retro and Project Health together? Would that provide enough time?
2. When would you like to schedule eng team co-works? Do you want to use one of the proposed holds, or add additional one(s)? (Since you all are in western-ish time zones, you probably have more flexibility.)
3. Would you like shorter/longer co-work holds? Fewer holds?
4. Any other feedback about this proposal?
5. Would someone like to volunteer to set up speed feedback sessions?

Calendars for reference

Here is the calendar spreadsheet that shows our availability during overlapping East Coast / West Coast hours, in case you want to propose alternate/additional times.

[ninamak]

@alexsoble @carjug Did y'all make progress on synthesizing the WINFY activity? I lost track in Slack of how far y'all got last week on "Agree on relevant team-wide norms and preferences."

[carjug]

@ninamak Alex made good progress on it before I could even get started! He's quick. https://docs.google.com/document/d/1fhBdfXHUNmfP2hsXO3bcWT8fefDaJjv-gFgjQ25Rv48/edit#

[ninamak]

Discussed idea of implementing a Tech Lead role for our team in 1:1s last week.

Next step: Discuss as a team what we'd expect a Tech Lead to be responsible for.

This is unlikely to happen this week before people start heading out (and there will be fewer people to coordinate while people are out), so we will likely pick this back up after July 4. Eng may have more guidance for us by that point, too.

[carjug]

@ninamak My personal responses to your questions for the team

1. I'd normally schedule Retro on Week A, but calendars make this difficult. How would you feel about rolling Retro and Project Health together? Would that provide enough time?

   • I am fine to try rolling Project Health and Retro into one, although I have a gut instinct that says that as this project gets more into a build cadence an hour will not be enough time, but I'm down to try anything as an experiment to see what works.

2. When would you like to schedule eng team co-works? Do you want to use one of the proposed holds, or add additional one(s)? (Since you all are in western-ish time zones, you probably have more flexibility.)

   • To answer your question with another question, would you feel like you were getting enough time with the team if we used up one of the proposed holds? Or do you think two co-working sessions a week would not be enough for you? (Of course, we can always try and schedule meetings or check-ins on an as needed basis too.) I could go either way and wouldn't mind finding another time given that we engineers are about to be in a high overlapping working hours situation.

3. Would you like shorter/longer co-work holds? Fewer holds?

   • I think for me, my max, except for in extenuating circumstances, is two and a half hours of solid camera time. And in this case I would prefer if we can establish a team norm/culture of one to two 5 - 10 minute breaks during long meetings.

Any other feedback about this proposal?

• Nope 👍

Would someone like to volunteer to set up speed feedback sessions?

• Is this something we could do during a co-working block, or is the proposal that we do it outside one of those blocks?

[alexsoble]

@carjug Oops, apologies if WINFY synthesis was something you wanted to take the lead on! Appreciate your review and edits!

[alexsoble]

@ninamak — Thanks so much for putting together the meeting cadences proposal!

1Q. I'd normally schedule Retro on Week A (marking the end of the sprint), but calendars make this difficult. How would you feel about rolling Retro and Project Health together? Would that provide enough time?

1A. I don't feel strongly about this one, we could try either way and see how it feels!

2Q. When would you like to schedule eng team co-works? Do you want to use one of the proposed holds, or add additional one(s)? (Since you all are in western-ish time zones, you probably have more flexibility.)

2A. As a starting point, we could try booking the first hour of one of the holds as eng team coworking. Then we can see if we end up needing more or less dedicated eng team coworking time per week.

3Q. Would you like shorter/longer co-work holds? Fewer holds?

3A. We can start with these holds and see how they feel. Agreed @carjug on breaks during long meetings! My understanding of these calendar holds is that they'd default to being not-meetings (heads down work time). With the holds on our cals, we'd have guaranteed time each week to cowork if needed.

4Q. Any other feedback about this proposal?

4A. Nope, love it! No meetings Friday! 😍 👍

5Q. Would someone like to volunteer to set up speed feedback sessions?

5A. Yes, I'd love to volunteer. However, the earliest I'd be able to set this up given my OOO would likely be week of July 5. So don't let me volunteering be a blocker on getting these started earlier if the team would like!

[amymok]

I'd normally schedule Retro on Week A (marking the end of the sprint), but calendars make this difficult. How would you feel about rolling Retro and Project Health together? Would that provide enough time?

I don't have any preference, but it feels like we do have a lot to discuss for each topic, so 1 hour for that may not work. Maybe 1.5 hour if schedule works (if we want to do it together)

When would you like to schedule eng team co-works? Do you want to use one of the proposed holds, or add additional one(s)? (Since you all are in western-ish time zones, you probably have more flexibility.)

Looks like we have potentially three co-working times. If we plan to use all three, we can at least use one for engineering cowork as a start. I would prefer more than 1 hour block for the engineering cowork. We can re-evaluate as we are moving to implementation, we may need less or more at that time.

Would you like shorter/longer co-work holds? Fewer holds?

I don't have a preference on short or long. But for long, it would be nice to have a break in between. I would prefer to have more holds so we have the time if we need it, and can cancel if we don't need them.

Any other feedback about this proposal?

No, this is great, thank you for putting a lot of thoughts in to this!

Would someone like to volunteer to set up speed feedback sessions?

I am happy to set them up, but did we talk about how we want to do this? 15- (or 30-)min session for each pair every two weeks? Or something else? During our scheduled co-work? Or other time?

[ninamak]

The Tech Lead role piece is now captured by #56

[ninamak]

Ok, I think I've got something worked out here. Moving Retro to Week A along with Project Health, but expanding to 1.5 hrs, with a break in between and after. So it'll be a heavy meeting day, but I'm hoping we can make it fun team time and not stressful meeting time. And the alternating week is much lighter.

I also scheduled Week A's to not coincide with the weeks when Eng Leadership is meeting so there's break time available.

Monday (Week A)

1-2pm ET / 10-11am PT: Sprint Demo (demo completed work and get feedback) 2-2:30pm ET / 11-11:30am PT: Break (add/update cards based on feedback, take a break, get food) 2:30-3:10pm ET / 11:30-12:10pm PT: Retro (reflect on team processes, dynamics, health, etc, and decide on experiments to improve) 3:15-3:55pm ET / 12:15-12:55pm PT: Project Health (discuss how project is going, which we will be more informed about post-Demo) 4-5pm ET / 1-2pm PT: Planning with Sheila (plan sprint's work, incorporate feedback from Demo as appropriate)

Monday (Week B)

3-4pm ET / 12-1pm PT: Grooming (refine upcoming plans & priorities for project) 4-5pm ET / 1-2pm PT: Sync with Sheila (touch base, discuss updates, etc)

Co-working I just put holds on our calendars for the times proposed so that the time is reserved. They can be flexibly used for heads down time, whole-team co-working, eng co-working, or some other combo. We'll have to figure out some system for keeping track of how we want to use the time.

Lemme know if this doesn't work for you. Otherwise, let's give it a try and see how it goes!

[carjug]

@ninamak Thank you for sorting calendars and proposing the schedule! This all sounds good to me.

[alexsoble]

One important team process I'd like to discuss and decide on as part of this work:

What are our processes/expectations for PM/PO review of PRs? (Hehehehe, PM, PO, PR!)

As an engineering team, we established that we want at least one other engineer reviewing and approving PRs before they merge.

For different categories of PR — features, refactors, bug fixes, ADRs, other technical documentation — which should have PM review involvement, and to what extent? @ninamak — I want to make sure we know when to pull you in, when to wait for your approval before merging, and when to just go for it!

[alexsoble]

Looking ahead on the calendar, I'm seeing a dense block of meetings (both @amymok and I have eng leadership in addition to the project meetings):

A couple of questions:

1. Since at this point we're writing documentation about initial choices rather than building features, would it make sense to skip Demos? The AM Demos meeting is internal-only, correct?
2. Could Retro and Project Health be one hour-long meeting, since they have similar themes? (Assess how the team is doing/feeling and what we want to change.) That could potentially give us some space and grace in between Retro/Project Health and 18F/MAPS planning.

@ninamak Appreciate all the work that went into crafting these schedules, I think I found it easier to visualize what they'll be like on the calendar as opposed to seeing the schedule on GitHub. I hope these questions are helpful!

[carjug]

In addition to @alexsoble's above questions, I also wanted to state a preference for not having co-working blocks that are longer than two hours. This week I've found that even with breaks I start to lose significant steam and interest in the topics at hand near the two hour mark.

[ninamak]

Ugh. Our big block of meetings was originally scheduled to alternate with the weeks when Eng Leadership meetings were happening. Either I messed that up, or the Eng Leadership mtg schedule changed.

In the original thread, people were concerned that 1 hr for retro + project health combined wouldn't be enough, which is why there are now 2 40-minute blocks. However, I agree that this is an unwieldy number of mtgs to have back-to-back. So if no one disagrees, I'd be fine trying us out at an hour and seeing how it goes. Especially since we're hoping to schedule speed feedback sessions, which could cover some things that might otherwise be reserved for Retro.

As for Demos, these will eventually be open externally. I need to confirm a time with Sheila first, which is why she's not on the invite yet. I'm open to skipping Demos when we don't have anything to demo, though!

[alexsoble]

Agreed with your points on coworking lengths @carjug! For coworking holds, we could simply cut the hold time down to 90 minutes or two hours. As an alternative, we could break the hold into a "synchronous" and an "async" part and have e.g. default 90 minute sync followed by async work time.

[ninamak]

I also think the amount of sync co-work we need to do will be on the decline. There's just been a lot of convos to have that the whole team has wanted to be part of. Which leads me to like Alex's suggestion of 90 min sync, 60 min async so that we still have blocks of time reserved for heads down time.

[alexsoble]

@amymok, what do you think about the above? [for when you have a chance to catch up on all the GitHub chatter!]

[amymok]

I agree we don't really need a demo at this point. It would be different when we start building.

We can try the shorter retro/project health, and see how that goes. If we need more time, we can talk about if we need to break it up into two different days.

I also agree with the long block of co-working time, it seems pretty hard after the 2 hours.

[ninamak]

Meetings for this week were adjusted based on feedback above.

Next steps:

• [x] Update recurring meeting schedule if we're satisfied with the changes we made this week
• [x] Update Project ReadMe with team norms and standing mtgs, links to team norming murals
• [ ] Determine the process we will use when multiple approvals (e.g., PM + dev) are needed on an issue
• [ ] Confirm with Sheila a time for a recurring Demo meeting - Will revisit this once we have things to demo

[ninamak]

To clarify what reviews are needed on an issue and in what order, how about the following:

• Add a Reviews Needed section to the GH Issue Template, and include options for 1 dev, 2 devs, PM, and PO.
• During Planning, remove any reviews we don't think we need to close out the issue, and specify the order in which reviews should take place.
• When an issue is ready for review, move it to the In Review column and update the Assignee.
  • If PR review is needed by devs, leave it assigned to the dev who did the work
  • If a review other than PR review is needed by a dev, assign to that dev
  • If review is needed by PM or PO, assign to PM or PO
• Once you have finished review, check off the task and update the Assignee if there are additional reviews needed

[carjug]

That sounds good to me @ninamak, the only thing I have questions about is if changing the assignees will be too annoying/burdensome/hard to keep track of and what about just tagging the next person up for review when it's time? Thanks fo your thoughts!

[alexsoble]

@ninamak We've talked earlier about the PM reviewing all PRs with the potential exception of security controls. Is it necessary for us to decide who needs to review per-issue, or should we have a default or standard review process that will apply to all issues?

Having a standard or default review process for all PRs might make things a little simpler and faster. Take a look at the WIP over here, does this sound right or was my understanding off? https://github.com/18F/OPRE-Unicorn/pull/69

[amymok]

If a review other than PR review is needed by a dev, assign to that dev

@ninamak I am unsure what this situation should be, what would be a review other than PR review by a dev?

[ninamak]

Responding to questions/suggestions:

if changing the assignees will be too annoying/burdensome/hard to keep track of and what about just tagging the next person up for review when it's time?

I find it helpful to be able to filter issues to those assigned to me so that I can easily see which ones are awaiting some action from me. Otherwise, I have to open each one and see whether there's a next step I'm responsible for, or just try to remember which ones I got tagged on. If there's another way to easily see which issues I need to do something on, I'd be open to that!

Is it necessary for us to decide who needs to review per-issue, or should we have a default or standard review process that will apply to all issues?

Good point. A standard process that leaves room for exceptions makes sense to me. For example, I envision that there are times when it would be helpful if both other devs reviewed a thing, not just one, because you want consensus or different expertises. Or that the PO is more involved. I'd like to include something on the template that reminds us to ask ourselves if an exception to our standard review process is needed, at least until we get more routine about these things. So instead of "Reviews Needed," it could be a section for "Modifications to Review Process." If we find we're never making any, we can get rid of it.

I hadn't seen the updates to #69, but that's a good summary. In terms of operationalizing that, we still need to figure out the order in which reviews happen. I'd propose that the default would be eng review first, followed by PM review (with the expectation that complex features might need eyes on WIP).

So then...how would eng like to signal to the PM that eng review is complete and it's ready for PM eyes?

what would be a review other than PR review by a dev?

I am thinking of things like reviewing a google doc or slide deck or something else that's an output of work but that wouldn't get committed into GH.

[carjug]

One more suggestion here @ninamak, with PRs specifically, it is possible to see all PRs awaiting review by you (if you're assigned as a reviewer). So my suggestion would be for PRs at least, that we don't change the assignee for the issue and instead add Reviewers to the PR as they're needed. LMK if this doesn't make sense or needs further explanation.

Below is a link in which you can see all PRs awaiting review by yourself. https://github.com/18F/OPRE-Unicorn/pulls/review-requested/@me

[alexsoble]

@ninamak I like the idea of a standard review process (PM + 1 other dev review) with the option to use different processes when appropriate. Things like PM + both other devs for tricky tech things, PM + PO + both other devs for big big changes, or lighterweight for things like fixing spelling, typos etc.

Eng review followed by PM review makes sense to me as you suggest! For some kinds of changes we could experiment with simultaneous eng/PM review.

I'll close out #69 for now and we can start with a fresh PR documenting the process we're discussing, we can feel free to lift some language or sentences from #69 if we want.

[ninamak]

Sound good! So then...how would eng like to signal to the PM that eng review is complete and it's ready for PM eyes? I'm still a bit unclear what's being proposed for that.

[amymok]

Right now I don't think we do signal it to a PM. Either the PM comes across and check each issue, if not, we can have the author takes a look at each of their own issues, and tag PM for review when all the reviews are finished by the engineers.

[ninamak]

Next steps that I'm aware of:

• [ ] Agree on how eng will let PM know when eng review is complete and ready for PM eyes
• [ ] Update "How we work" to include the overall review process we've discussed here.

In terms of the first task, I'm amenable to whatever works for you all. My requirements are just that I have a way to see everything that is awaiting my review without having to go into each issue or PR and check, and that my review is requested after preceding reviews have been completed.

[carjug]

Reviews process proposal

I have created a set of "review" labels for the team. See them here: https://github.com/18F/OPRE-Unicorn/labels?q=Review

I've assigned a review label for everyone to this issue. See the example here, when I filter by "Alex Review" https://github.com/18F/OPRE-Unicorn/issues?q=is%3Aopen+is%3Aissue+label%3A%22Alex+Review%22

For issues without PRs

• When issue is ready for review, move to "In Review"
• Add ____ Review label for those who need to review and also comment, tagging them on the issue stating that it's ready for their review
  • If reviews need to happen sequentially, add just the label for the first review, then when the first review is done, remove the first and add second label and so on....
• To see all issues with your "Review" label go to: https://github.com/18F/OPRE-Unicorn/issues?q=is%3Aopen+is%3Aissue and then select the "Labels" dropdown and click the label that corresponds with your name. You can save this search as a bookmark for one-click access to what issues need your review.

For issues with PRs

• At least one developer and one PM as reviewers
• When issue is ready for review, move to "In Review"
• Add developer reviewers to PRs when they're ready for developer review, doing so will send a notification to the reviewers stating that their review is waiting on said PR
• If PM needs to review the PR (this will probably be rare), add them as a reviewer when the PR is ready for PM review.
  • To see all PRs assigned to yourself see: https://github.com/18F/OPRE-Unicorn/pulls/assigned/@me
• If PM does not need to review the PR, but still needs to review the ticket, add Nina Review or Sheila Review label to issue depending on who needs to review.

How does this sound @ninamak @amymok @alexsoble ?? My only thought is that maybe we'd want to use the labels for all reviews including PR reviews (in addition to the "reviewers" function on PRs)? I'm happy to check both PRs assigned to me and the issues label view, but understand if folks just want one place to look.

[alexsoble]

@carjug Oooh, I like it! I think the use of labels is a creative [and colorful!] way to communicate about review for issues without PRs!

I think juggling the two different ways to request review — labels and the PR review functions — could get clunky, like you mention. So I think I'd prefer having just one way to request review and indicate approval for any given issue. But that's a weakly held preference, we could try doing both.

[amymok]

I don't have a strong preference, I can do whichever way we settle on. Thanks for the suggestion @carjug!

[ninamak]

This works for me! I think with this process that tagging the person along with adding the label is key. The tagging alerts the person, the label lets them keep track.

[carjug]

Great! Thanks team.

So, for PR reviews lets make a habit of both adding reviewers to the PR as well as adding the label to the issue for whoever needs to review, just so there's a one stop shop for all reviews needed :) and also tagging the reviewer on the issue in a comment when it's ready for their review

Moving to done!

CC: @amymok @ninamak @alexsoble

[carjug]

Record scratch, unless there's somewhere we'd like this documented??

[ninamak]

LOL, we agreed yesterday to document this in How We Work -- both who needs to review what, and what the process for reviews will look like.

[carjug]

Clearly did not remember that, LOL. Ok I will document and assign everyone to the PR when it's ready for review (since all your Review tags are already added to this issue lol)

[carjug]

@amymok @alexsoble @ninamak ready for review!

[alexsoble]

👍 👍

[carjug]

Hey @alexsoble not sure if you saw my comment on the PR that CC'ed both you and Amy. I saw your above comment and wondered if perhaps you got the notification that I tagged you but missed the thread where it was at (in the PR).