Team practice for short-term planning and coordination

[choldgraf]

Summary

We've been trying out a workflow recently based around deliverables and project boards. You can find a description of this workflow here.

As we try out this workflow, we should think about ways that we can improve these processes, structure the boards, etc. Let's leave this issue for a month or two to collect feedback and iterate on ideas, and we can close it once we are happy with the process.

Questions to answer

• Overall board structure / meaning
  • What kinds of issues go on deliverables boards vs. on activity boards?
  • What does it mean for an issue to be in a deliverables board?
  • What does it mean for an issue to be on the activity board?
• How do we encode discussion questions?
  • Via Issues, GitHub Discussions?
  • How do we signal-boost them? (e.g. put in "needs review", put in "needs discussion"?)
• "Info board column"?
  • Does it make sense for us to use an "info" column for ongoing information? (sort of like an "announcement board")
  • If so, what rules should we put in place for this so it doesn't become super large?
• Proposal: Agile process around the boards
  • Shall we roughly follow an "agile" approach to these boards, and use our deliverables sync meeting to plan out the next two weeks of things to follow?

Actions

We'll test out a new process for the deliverables sync meeting + board workflows for about 3 months. These action items will keep track of questions to answer as we go through the process.

• [x] Discuss board workflows in the next team meeting #186
• [x] Review our deliverables review meeting notes and decide if/how the structure should change https://github.com/2i2c-org/team-compass/issues/174
• [x] #201
  • https://github.com/2i2c-org/team-compass/pull/188
• [x] https://github.com/2i2c-org/pilot-hubs/pull/592
• [x] #205
• [x] #214
  • [x] Prototype 60 minute meetings Until October 1st and make a decision then whether to move to fortnightly.
• [ ] ...fill in items here as feedback is incorporated
• [x] Decide whether to revert back to bi-weekly meetings for deliverables sync.
• [ ] Write up the process we've arrived at in the team compass

[choldgraf]

Some thoughts from the last deliverables sync meeting and recent conversation with @GeorgianaElena:

• Frame the activity board in terms of "actions that 2i2c team members should take"
• Separate out "blocked and waiting" columns
  • Blocked means that a team member should help un-block somebody
  • Waiting is something where a non-2i2c person needs to take action
  • (@yuvipanda I think you're the one that described this, let me know if this isn't quite right)
• The "info" column could be a place to store "ongoing information and reminders" about things like:
  • Who is the current support steward?
  • Important upcoming dates
  • Issues that ask for ongoing feedback from everybody and won't be closed with a single action
• Reframe the difference between "deliverables" boards and "activity" boards to be about complexity rather than about "deliverable vs. task". Tasks can be complex and multi-step as well, so this can be a confusing breakdown.
  • One rubric: "deliverables generally take > 3 days to complete, tasks are finished in 0-3 days.
  • Another rubric: "deliverables are often made up of many steps or components to accomplish. Each step should be on the activity board, and the high-level issue should be in the deliverables board".
  • Another rubric: "the activity board should have items that are close-able with a single, relatively straightforward PR"
• In general we should put Issues on the project boards, not direct links to PRs. If you've got a PR, link it to the issue so that it will close the issue when merged. If this is done, then a link to the PR will automatically show up for that item in the Activity board.

@GeorgianaElena let me know if I missed something.

[choldgraf]

• Have two "Done" columns -
  • a regular "Done" column
  • a "Done Archive"

Before every team deliverables review meeting we move all "Done" cards into the "Done archive" (I believe we can automate this with a GitHub action)

[yuvipanda]

I'm currently a little overwhelmed by the boards, and want to move around the process a little to help with that. Specifically, I was wondering if we could:

1. Unify to one board, not two
2. Keep the level of items in the board very high, so there's not too many of them. Currently almost all the columns in all the boards have too many items for my brain
3. Use more GItHub native features (like assignment and reviewer requests) over using a board to signal that information via columns

[choldgraf]

We discussed this in a recent team meeting, and agreed on the changes that are encoded in this PR: https://github.com/2i2c-org/team-compass/pull/188

[choldgraf]

After some recent conversations, I wanted to note a few more thoughts and proposals, and see if this should feed into an update to our team processes at all. I'll write out general notes below in case others have ideas, and we can figure out how to work them into our practices in the right way.

A few challenges

Our current coordination / sprint planning process is improving and evolving nicely! One thing that I have noticed (and have discussed with others) is that it still doesn't address a few specific challenges:

sprints as team events

• We should treat our sprints as collective efforts, not as individual tasks that we complete on our own. Assigning multiple issues to each person seems to be encouraging each of us to work independently and this means we are missing opportunity to work together as a team on things.
• We don't want everybody "at capacity" in the work they've picked up for a given sprint, because then we won't have time to review one another's work and get them merged.

not missing the refinement / discussion process

• The sprint planning process is good at selecting work to do now, but it doesn't say anything about how we can refine and discuss issues that are coming down the pipeline (see #205 for a related issue there).
• We should ensure that the team has space to discuss and get these issues ready to work, so that our backlog is higher-quality and so that we have more shared context when it's time for sprint planning.

Some ideas to improve this

Here are a few ideas for improving this that came out of a recent brainstorming session from @damianavila

Reduce sprint workload

Stop trying to ensure that every person has a full workflow for each sprint. We should intentionally reduce the "available capacity for sprints" so that people have more time to review one another's work and discuss other issues. Right now we roughly shoot for 1-3 issues per person, per sprint. What if instead we tried a process like:

• Each team member should have between 0 and 2 issues per sprint.
• If you don't actively have work to do on your sprint issues, you should spend your time reviewing the work of others
• If there is no other work to review, you should spend the time discussing and refining issues in our deliverables backlog

Sparingly use an issue label to encourage discussion

Use needs: discussion to focus attention on particular issues on our backlog. We should set a limit like "only 3 issues can have needs: discussion on our backlog at once". The goal of discussion is to scope the issue properly, split it up if needed, and have a clear path to implementation. everybody should participate in this process so that we have more shared context about what we'd like to do next.

Define a Sprint Steward role

This role would complement the #205 as another one of the key roles that we have on a team. The Sprint Steward's job is to ensure that our team processes are flowing smoothly, that PRs are reviewed quickly, that continuous issue discussion / refinement is happening, etc. In addition, they should be watching for opportunities to improve our process, or moments when process is breaking down and it is time for an intervention. The sprint steward's responsibilities would be something like:

• Facilitate the sprint planning meeting
• Keep an eye on anything in the "doing" column and ensure that the work there isn't blocking on anything, and generally moving forward
• Keep a close eye on anything in the "Review" column, and ensure that people provide feedback within a reasonable timeframe
• Notice the total workload across the team and suggest re-scoping of work if needed
• Work with the Backlog Steward to ensure that discussion is happening on issues that have been flagged as needing discussion soon.

(I see this as similar to a "srum master" role that is often used in Agile Teams, with our Backlog Steward role being a parallel to the "Product Owner" role)

[damianavila]

@choldgraf, thanks for putting into words the ideas we have been discussing recently.

Regarding the last item, I am wondering if, at this time, the Backlog Steward and Sprint Steward should be the same person since the information coming from the backlog role surely will feed the sprint role actions (in that way we also reduce the miscommunication from one role to the other one).

[choldgraf]

@damianavila yeah I think that is reasonable, and also in a sense it is realistic since we have a small team. I think there's still value in defining the roles separately, just so it's explicit what kind of work needs to be done. Does that make sense?

[damianavila]

I think there's still value in defining the roles separately, just so it's explicit what kind of work needs to be done. Does that make sense?

Sure, I was not implying to merge the roles, just ask the person to use 2 hats :wink: .