Update team meetings and deliverables workflow

[choldgraf]

This PR updates our team workflows after a recent team meeting to discuss our Deliverables review meetings and how it fits in with board workflows. It also updates guidelines about meetings in general that we have recently discussed.

Major updates:

• Deliverables meeting is now weekly, with a noted plan to move back to bi-weekly
• Remove the dev/org backlogs from "official" team process, but includes description of them in case it's useful
• Simplifies language around the activity board and deliverables structure
• Updates our meeting templates with this new structure
• Encodes official meeting roles in the templates+docs

closes #201

[sgibson91]

LGTM! I have one tiny Q but isn't a big blocker.

[choldgraf]

hey @2i2c-org/tech-team - I've updated this PR and expanded its scope a bit to encompass our team meeting discussions. It now tries to encode the changes that we suggested in that meeting. LMK what you think!

[yuvipanda]

Thanks a lot for writing this up, @choldgraf!

[yuvipanda]

How about instead we just have one board, where the goal is purely prioritization? It has just high level tasks, and only contains an ordered list of deliverables that can be picked up. Nothing is automatically put into this board - someone must develop an issue to a point where it is ready to be worked on, and explicitly puts it in this board with appropriate priority ordering. We can then use this to pick up tasks from when needed.

[choldgraf]

Mmm - I like the idea of keeping track of prioritizes and high-level deliverables. Though have a few concerns with "one board to rule them all".

1. It doesn't track the overall structure and plan of work in a given project, so will be less useful at understanding the "big picture" of why a particular deliverable should have priority. This will also make it harder to know which deliverables go at the top of the list.
2. Many of our projects are totally different from one another, and some team members will have workstreams that don't overlap (e.g. myself and @damianavila are doing a lot of stuff on Jupyter Book projects...would it feel weird to have those deliverables interwoven with things like pilot-hubs/ upgrades? How would we prioritize one deliverable over another in these cases?
3. I think the "Someone must develop and issue" process is actually a really important process, and I'm a bit worried that we are being kind-of hand-wavy about how it happens. For complex issues, once we've gotten to the point of "somebody just needs to implement it", a lot of work has already been done. How do we use these workflows to ensure that this happens?

[yuvipanda]

Agree that (3) is super important, and I responded to some of that in #188 (comment). I think most work is iterative in different kinds of work, and it is difficult to get them to a point where "somebody just needs to implement it" happens. I think doing that kind of work should just be part of the sprint - maybe for one sprint half the work is just getting an issue fleshed out and decisions made (if necessary) with other people.

For (2), I think it's ok to have them mixed in for now. If absolutely necessary, we can filter by labels (or repos). Let's try it out and see if it is a problem?

For (1), IMO we should rely on the content of the issue, since most of it will be pretty unstructured. I don't know if moving them across columns in a board provides more information than text in an issue. Since almost all our work interacts with folks from outside 2i2c, and they don't really expect to be using our boards, we should just continue using issues until we hit more specific problems there.

Anyway, I think (3) is the most important thing to do. I don't think adding 1 board per project will help with that though - you still have to remember and check which board to look at, and do the work. Keeping it in the issue, and not treating it differently from implementation work alone will help reduce diffusion of responsibility too

[choldgraf]

re: (1) I think for some projects we will hit a wall of how much organization we get from a single issue w/ unstructured content. Either way, I think we can leave this up to the project to decide how they wish to organize high-level structure...it doesn't have to be a part of the core team workflows (AKA, I don't want us to say "you are not allowed to use a GitHub Project Board even though you think it's the right way to structure the project").

re: (2) How do you imagine this being different from the "Development Backlog" that we have already been using? Is the main difference that it is more disciplined and refined than the current one? It feels like the current dev backlog wasn't working for folks, so I'm trying to understand where this differs to make sure we don't just create another board that folks don't find useful.

re: (3), then my main question is what do we mean by "someone must develop an issue to a point where it is ready to be worked on" in order to be added to the deliverables board. What's the criteria for "this can now be added to the board"?

[choldgraf]

Since this hasn't yet been merged, and we potentially have not yet converged, let's just stick with our pre-planned meeting time and have the normal team deliverables sync on Tuesday. I'll spend Monday trying to clean up our backlog a bit and we can run the meeting like a sprint planning meeting, even if we'll begin on a Monday the next time around.

[damianavila]

I think we should do a triage of the issues in the deliverables backlog (https://github.com/orgs/2i2c-org/projects/7) to make sure that it accurately reflects the work that we want to do. Ideally this is work that should be done before the Sprint Planning meeting, but I'm not sure the best way to incorporate this into our practices.

IMHO, triaging the backlog should be done by the team instead of just one person.
I would totally invest 15-30 more minutes in the meeting to approach that collectively, IMHO.

[choldgraf]

Hey all - I just pushed another update with some more guidance about the breakdown of deliverables/issues/etc. I think that we are relatively converged on a pattern to try out here? Let me know if there's anything outstanding to change.

[choldgraf]

@damianavila I agree that the deliverables refinement should happen with participation from the team as well. Do you think that this is something that all team members should be present for, or could we accomplish this via more focused meetings throughout the week?

E.g., I was imagining that we could have a role like "Backlog Steward" we could rotate on a 1-2 month basis, and that role's job would be to coordinate with team members in focused meetings to update deliverables on the backlog. Those meetings could be "public to any team member, but with only 1-2 people we are scheduling around".

(that said, I'd also be in favor of extending our weekly planning meeting to add a 30 minute deliverables backlog refinement session, just throwing this idea out there to see if it resonates)

[GeorgianaElena]

Extremely grateful for everyone's work and ideas towards improving our team practices. Also, thank you for trying this out and sorry for missing the first iterations of it.

I like the direction in which this is going and how the things seem more simple and have a more straightforward implementation path.

I left a couple of comments about the things that sounded a little confusing for me.

[GeorgianaElena]

I am a bit confused about these common sections:

• the deliverables definition above made me think about deliverables as being any type of GitHub issues (enhancement, bug fixes, admin stuff)
• but these common sections seem to be the sections of the new-enhancement issues

Are deliverables just enhancements, possibly made up of smaller tasks?

[choldgraf]

I think that the structure should work for enhancements or admin stuff, though I suspect that bugs might benefit from its own dedicated issue structure (e.g. since it's often important to note environment details etc).

What if we re-named this from new-enhancement to new-deliverable? We could use labels to track what kind of deliverable it was (e.g. admin, development, etc). I'll put that in a commit and let me know how it reads

[choldgraf]

thanks for these comments @GeorgianaElena ! check out the latest commit, which I think addresses them

[damianavila]

@damianavila I agree that the deliverables refinement should happen with participation from the team as well. Do you think that this is something that all team members should be present for, or could we accomplish this via more focused meetings throughout the week?

That is a thought one!! I am not sure... I see benefits and cons to both approaches. Maybe we can pick one and try it and see how that works out for real?

[choldgraf]

@damianavila how about we start off with some meetings with subsets of team members, and see how this feels from an "information silo" perspective. We can revisit in our team discussions if we think it'd be useful to have an "all hands" style meeting for this.

This could also potentially be something that we work into our "one on one" practices. Review major work items that are in the backlog, clean them up and reprioritize as we get new context, etc.

[damianavila]

@damianavila how about we start off with some meetings with subsets of team members, and see how this feels from an "information silo" perspective. We can revisit in our team discussions if we think it'd be useful to have an "all hands" style meeting for this.

I am OK with that.

This could also potentially be something that we work into our "one on one" practices. Review major work items that are in the backlog, clean them up and reprioritize as we get new context, etc.

I am not OK with that 😉 because that automatically puts you as the Backlog Steward and that should be a rotating thing (as you imply in the subset proposal you made?). Unless you are referring to "one on one" as a broader thing and not our weekly 1:1 with you.

[choldgraf]

@damianavila I agree with you! I meant "general team 1 on 1 practices". But, I agree with you that right now that would effectively just mean myself because I'm the one with the most 1-on-1s with everybody :-)

It feels to me like we should define this "Backlog Steward" role explicitly, and rotate through it similar to the Support Steward. The Backlog Steward's job would be to facilitate 1-2 weekly "backlog refinement meetings" with one or more other team members.

[choldgraf]

What's the pathway towards getting this merged, and iterating later?

@yuvipanda you've requested changes, can you approve or make comments about further changes?
@damianavila do you feel that we should define the Backlog Steward role before merging this PR? Or something to track in ongoing iterations?

[damianavila]

It feels to me like we should define this "Backlog Steward" role explicitly, and rotate through it similar to the Support Steward. The Backlog Steward's job would be to facilitate 1-2 weekly "backlog refinement meetings" with one or more other team members.

I would agree with that.

@damianavila do you feel that we should define the Backlog Steward role before merging this PR? Or something to track in ongoing iterations?

I would be OK with ongoing iterations (modulo we capture those things in another ticket). Approving now.

[choldgraf]

Sounds good - I've opened up #205 to track the creation of this role

[choldgraf]

OK all - we've had several rounds of iteration and reviews that I think are now addressed. I've got approvals from 3/4 folks and I think that @yuvipanda is happy with what remains. I'll plan to merge this tomorrow (Saturday) unless I hear otherwise, and our next sprint meeting will be on Monday.