Add a regular asynchronous team check-in

[choldgraf]

Description

Now that we've merged to two-week sprint cycles as part of https://github.com/2i2c-org/team-compass/issues/182, it might be helpful for us to have a lightweight way for us to check-in with one another throughout the week. In a team meeting, there was interest in trying out an asynchronous team check-in process. It would have the following goals:

• Be an opportunity to ask for feedback or input
• Help team members provide accountability and transparency to one another
• Identify opportunities to coordinate or hand-off work
• Identify whether there are unexpected challenges we didn't anticipate when scoping work
• Provide ourselves an easy way to look back and see what we've been up to this week/month/etc
• Help us focus on just one or two things at a time, and not spread ourselves across too-many daily projects

In addition, it'd have these constraints:

• Must be very lightweight - responding shouldn't require any "thought" and should only take 30-60 seconds
• Should be asynchronous, and not require people to respond at awkward times
• Should be followed by all team members (and should be light-weight enough that it's not a chore to maintain the practice)

Value / benefit

Having a practice like this will make it easier for us to signal to one another what we're up to throughout the week, since we have less time to speak with one another face-to-face in our planning. Having a lightweight check-in process will help us accomplish the goals in the description above.

Implementation details

In our meeting we had discussed something like a check-in every couple of days, but after thinking about it a bit, I think it might be the easiest if we just try to adopt something that is daily on weekdays. I think having it each day will make it more likely to just become a habit, and will also force us to keep the process lightweight enough that it does not feel like a chore to carry it out.

So I propose that we do the following:

• For the next 2 months, we try the following process and revisit in December 2021.
• When: Wednesdays and Fridays, but skip Wednesdays with sprint planning. AKA, every Friday, and every other Wednesday. At 5:00pm India time (or 5:00pm in each person's time zone if we can figure it out).
• How: Use a Slack reminder (or if it is too clunky to do this at the same time for all w/o changing time-zones, use the Geekbot)

• What: A DM that is sent to each person, or a questionnaire that is posted in a channel, with these questions to answer:

  • How are you feeling today? ✨
  • What did you work on today? 💪
  • What are you up to next? 🏃
  • Would you like help with anything in particular? 🙏

  When you answer them via the DM, they'll get posted to the #team-updates channel

That's it!

In 2 months, I think that we should re-discuss this and answer the following questions:

• Does this practice accomplish the goals listed above?
• Is the frequency OK?
• Is this a replacement for our weekly team sync, or should they both live in harmony?

Tasks to complete

- [x] Iterate on the plan above if others have feedback
- [x] No objections to the plan above
- [x] Try out this practice for 2 months
- [x] Discuss in December 2021
- [x] Switch to using only Slack for the check-ins
- [ ] Create a quick way to aggregate our Slack updates and post them publicly
- [ ] Understand why we have a drop in responses and decide what to do about it https://github.com/2i2c-org/team-compass/issues/259#issuecomment-1531194231

Updates

2021-10-04 - Updated the proposal above with a new cadence

(see https://github.com/2i2c-org/team-compass/issues/259#issuecomment-933884622)

2022-01-10 - Switch to Slack-only updates

In general the team like the Slack bot updates, so we've decided to switch exclusively to those. The main concern about this was that our work would be less public in general, so we agreed to find a way to "summarize" and share our activity over some longer period of time. Updated the tasks above with these new changes.

[damianavila]

Overall +1 although...

Is a daily stand-up too frequent, or should we scale it back a bit (e.g., MWF)?

I will start with that frequency instead of the daily one. I have the "feeling" a daily standup would usually be just a "copy-paste yesterday (because I am still fighting this 😜 )".

[sgibson91]

Ooof, yeah - daily sounds like a lot. I was expecting this check-in to be in the off-weeks from the sprint planning meeting as we don't want people to be waiting til that meeting to raise concerns.

[damianavila]

Yep, I concur with the off-week check-point. Even more when we have already have a weekly Monday sync.

Without that one (Mon sync), I would probably see something the following ones:

1. Sprint meeting
2. Next Monday
3. Off week checkpoint
4. Next next Monday

like a good cadence since we would have "syncs" every 2-3 days.

[choldgraf]

Thanks for the feedback - it sounds like daily is too much for folks. A couple quick thoughts:

My main concern w/ infrequent check-ins is that this should become a habit - it should be quick and low-effort and something that you just "expect" to happen. It shouldn't take longer to accomplish than brushing your teeth. I worry if it doesn't happen semi-regularly then it'll be more likely that people will forget to respond, or that they'll feel the need to report on a bunch of stuff and it'll take longer to do.

I also don't imagine (in its current form) that this would replace the Monday check-ins. In my experience, those require more effort because I have to track down issues etc. People often posts lists of multiple issues in those responses. For these check-ins, I imagine them being much shorter. Maybe like 1 sentence per question and at-most 2 links to issues per response, something like that.

I also don't think that our sprint planning is the same as these kinds of team reports. The Sprint Planning meeting should be a planning meeting, not a team sync meeting. I think if we spend more time sharing context in these regular check-ins, we can focus that meeting more on the "next steps and discussion" and less on "what have you been up to".

Proposal

How about we go with Tuesday and Thursday for these check-ins? In December if we decide to replace the Monday weekly syncs with this, then we could switch to M/W/F instead of Tu/Thu. Would that work?

[damianavila]

How about we go with Tuesday and Thursday for these check-ins?

I would be OK with that. Some caveats (because sometimes, well maybe usually 😜 , I am an annoying person):

• the first Thu people will not have too much to say
• the Tue before the Wed Sprint meeting is probably not useful because the sprint is essentially done

[choldgraf]

Another proposal :-)

@damianavila et al How about:

Wednesday and Friday, but not the wednesday of our sprint planning meeting. AKA, "every Friday, and every other Wednesday".

If we replace with the Monday team syncs with this in December, then we just switch to M / W / F and skip the update for Wednesdays where we have sprint planning.

Is that better?

[sgibson91]

Some caveats (because sometimes, well maybe usually 😜 , I am an annoying person):

FYI, I appreciate you thinking about the failure modes and why this may become a chore as opposed to the habit Chris is aiming for.

Wednesday and Friday, but not the wednesday of our sprint planning meeting. AKA, "every Friday, and every other Wednesday".

This sounds like a good place to start to me.

If we replace with the Monday team syncs with this in December

One of the things I like about the team sync is its transparency. Those issues happen in a public repo that anyone could look at and see how we organise ourselves and support each other. And I think we'd lose some of that if we replaced that with a slack check-in.

[damianavila]

Is that better?

Yep!

FYI, I appreciate you thinking about the failure modes and why this may become a chore as opposed to the habit Chris is aiming for.

Thanks!

One of the things I like about the team sync is its transparency.

That's a very good point!

[choldgraf]

OK cool - let's go with the proposal I've described above unless another team member suggests a change. I'll try it out with a Slack action tomorrow and we can see how weird it feels to have a bot talk to you on Slack 😅

I think that approach won't do it on a timezone-specific way, so I'll have the bot send out a ping to everybody on the tech team at 5pm India time on Wed, and we'll see how that goes :-)

[choldgraf]

I'm gonna consider this one done for now, but we can leave the issue open so that we loop back to it in a couple of months and decide how we like it (we can also make tweaks to this process if we want in the meantime, but probably don't need a dedicated issue for it :-) )

[choldgraf]

I'd love to hear thoughts from the @2i2c-org/tech-team about how this is going. What do people think about each of the three options below:

1. Close this issue and stick with our current pattern of "github issue on Mondays, slack check-in on wednesdays/fridays".
2. Use Slack updates for all team updates and stop using GitHub issues for team syncs. I've heard from some folks that they prefer Slack in general, so maybe we should just go with it?
3. Make some other change and please note what you'd like to see below!

[sgibson91]

Use Slack updates for all team updates and stop using GitHub issues for team syncs. I've heard from some folks that they prefer Slack in general, so maybe we should just go with it?

My only -1 on solely using Slack is that it is not as transparent (public) as the GitHub issues. I think we should have a discussion about how transparently/publicly posting updates fits in with 2i2c's values before we make a final decision.

[damianavila]

Yep... I would be also inclined to just use ONE tool (most likely Slack) for the sake of simplifying the UX at the time to report. I think we need to communicate what we do, but I am not still convinced the weekly GH report is granular-compatible with a 3rd party reader. I think a monthly blog post with condensed but linked information would be something better.

[choldgraf]

I think I agree with both of you - I share @sgibson91's value for transparency, but also see the value in just having a single tool / workflow rather than one tool on some days, and another tool on other days.

That said, I wonder if there is a better (more discoverable, higher signal-to-noise, etc) way to share out our activity publicly (e.g., a monthly "2i2c changelog"?) and then we can cleanly separate our "internal team coordination" practices from our "external communications and transparency" practices.

[sgibson91]

I think scraping the bot responses over, say, a month to help compile a blog post could be a path forward (I say help compile as there may be irrelevant stuff in the responses for a blog post!)

[choldgraf]

That shouldn't be too hard to do. Shall we switch to slack check-ins on MWF and then experiment with ways to surface out activity publicly each month? Anyone object to that plan?

[choldgraf]

Update - switched to MWF

Per our conversation above, I've made these changes:

• The Geekbot will now ping us on Monday/Wed/Friday
• I've opened up https://github.com/2i2c-org/team-compass/pull/347 to change our processes accordingly

[choldgraf]

Team members seem to be using this less and less

I want to give another data point here, which to me suggests that we should adjust this practice somehow. I've noticed that team members are using this less and less frequently over the past few months. For example, if you count the average number of responses for each team member, it looks like this:

A heatmap plot that breaks it down by person suggests that only 1-3 people are regularly responding, and most others are not responding much at all[^1].

[^1]: Not showing this publicly because it makes it pretty easy to identify people based on the patterns there and my goal here is not to out individuals but instead describe team patterns.

I'm not sure what to do with this information but I wanted to record it here to share context. I'm not sure if people aren't responding because they find it too cumbersome, or not useful, or the questions aren't right, etc. But either way, folks don't seem to be engaging in this practice and it thus is likely not having the intended effect of sharing context and asking for help in an async way across the team.

edit: accidental close!

[sgibson91]

I stopped responding to this because I was seconded to JupyterHub CSL work, but intended to re-engage upon my return.

[yuvipanda]

I stopped responding for about 2 months consistently because I was overwhelmed and out of it for other reasons, but am doing better now and engaging! So maybe it's a correlation of how good I'm feeling? :D

I do think the timing matters. Friday and Monday seem not the most useful days for this together?

[sgibson91]

Maybe instead of a MWF cadence, we try a Tu&Th cadence? I feel much more confident articulating what I'm up to next on a Tuesday because I've spent Monday going through updates and seeing the rest of the team come online and what their priorities are/how it fits in with my priorities.

[yuvipanda]

YESSSSS TO @sgibson91

[choldgraf]

Just another few datapoints from other orgs.

Basecamp does:

• end of each work day: "what did you work on today"
• beginning of each week: "what are you working on next"
• and less-frequently they answer more personal/social questions like "what's something you did recently outside of work"

From https://37signals.com/how-we-communicate/

Also some interesting discussion from a gitlab team here. Looks like they are reading some similar material as the Basecamp folks.

https://gitlab.com/gitlab-org/manage/foundations/team-tasks/-/issues/3

One thing I'm noting either way is that our standup has a lot more questions than most groups tend to use (which it seems is usually limited to 1-2 questions).

[damianavila]

For me, it is also a frequency matter, MWF is too much and M/F are particularly less useful. I would probably feel better with a T/T and even less: only a Wednesday update, a clear midpoint, so you can answer about things you did and things you will do, plus all the personal/social-related answers. Additionally, if we only have one weekly update, it might be interesting to have a bot command for personal/social impromptu stuff that I feel will be more frequent than once a week.

[damianavila]

Well... rethinking this one, probably a T/T is the minimal change we can come up (just update frequency) that I think will have a significant and measurable impact. So, maybe we try that for a few weeks and re-analyze?

[yuvipanda]

Yep, let's move to T/T and see where it goes

[consideRatio]

:+1: for a transition from MWF to TT!

[choldgraf]

Proposal for async updates

Thinking about the above suggestions, I wanted to propose something to try next.

• Every Monday morning (weekly)
  • What's on your mind? You can share anything you're thinking about or concerned about, something you did over the weekend, etc.
  • Would you like to give thanks to anybody?
• Every Tuesday and Thursday evening (twice a week)
  • What have you recently accomplished?
  • What will you work on next?
  • Where are you blocked in moving forward?

My rationale here is that we want to build a more reliable team practice around team members reporting out what they're working on, and having these in dedicated questions will lower the barrier to doing so. I also think we should create a team expectation that everybody answers this question and everybody looks at one another's responses to provide async guidance.

To be honest, my initial feeling was that we should actually just follow a standard agile practice of doing the "3 questions" every single day. But I worry that if we already have challenges in response rate, this will be too much too quickly. However I'd suggest we consider increasing frequency if we feel that doing it on T/R results in team members feeling blocked and without guidance.

What do people think about this re-work?

[sgibson91]

Whenever I'm asked what I've accomplished, all of the things I think of are never contextually relevant to the person asking. Quite often I'll feel the true answer is "nothing in particular" but will put something flippant to appear like I'm participating. Maybe just "what have you done?" which feels more factual than framing it as an accomplishment because, hey, as human beings our purpose on this planet is not to be productive 24/7.

I also feel like the question "what will you work on next" is always a tricky one. Like, I could just answer that with "please see issues assigned to me on the current sprint board", or it might be "I don't know, I'm awaiting another sprint planning session". Or maybe I've completely nerdsniped myself into something totally unrelated.

I generally think these kind of agile practices are really difficult to participate in if you're not feeling proud/excited to share or are unclear on what you're supposed to be doing, as alluded to by Yuvi above. And yes those scenarios need to be surfaced and addressed - but declaring that to a bot which puts them out into the ether for someone to maybe notice doesn't always feel great?

[jmunroe]

Regular (biweekly) check-in make sense to me only if there is a sprint ongoing and significant progress day to day is anticipated. When a team member has been working on issue but it not completed (state the accomplishment!) or blocked (ask for helped) but just in that middling state of "working on it" it feels odd to write that out.

Is the stand up really more on where we are are on particular open issues assigned to us? I'm torn on requiring writing regular status updates -- if I need to be creative and come up with a nice way to summarizing what have done/currently doing, there is a self-doubt on exactly what to put down. If we make it too formulaic and focused solely on issues progress update that is already encoded in issues isn't that just busy work?

[choldgraf]

I really appreciate this feedback - thanks for being honest about how these kinds of practices may be counter-productive or even discouraging. We should be thoughtful about the practices that we commit to and make sure they will have the effects that we want.

My feeling is that figuring out the right mechanisms for check-ins and accountability is important, but it a complex topic to get right and it's not the right moment to make a significant switch in those practices right now. We're already changing other aspects of our process around goals and strategic planning, so let's focus on that for now, and revisit conversations about asynchronous team practices over the coming weeks, perhaps as part of retrospectives.

[damianavila]

FYI, I am updated the Geekbot to accommodate the stand-down process described in the new sprint workflow (as a new Tue/Wed/Thu Geekbot workflow) and edited the current team sync to only contain the "more general questions" to be asked only on Monday mornings. Let's see how that work for a few weeks!

[haroldcampbell]

I’d like to resume conversations regarding the current use of the Geekbot for stand-downs and compare that with the purpose of Basecamp's process listed above.

Why

We need to improve our asynchronous mechanism for coordinating work.

How

Shift from bot prompted update in the team-updates to team-specific channels

Context

We are a remote first organisation with a small group of people who are:

• split in 2 general time zones: Americas (Argentina, Canada, Jamaica, US) and Europe (Romania, Sweden, UK).
• split into 4 teams: product, engineers, partnership and community support, operations.

Coordination is important to get work done and there is a fair amount of conversations that happen in various places: email, slack, github issues, various documents, huddles, real-time conversations, etc. We also use github project boards to track the work that we do (via issues).

We use Geekbot to ask:

• end of each work day: "what did you work on today"
• beginning of each week: "what are you working on next"
• and less-frequently they answer more personal/social questions like "what's something you did recently outside of work"

Opportunity & Proposal

Currently, we have a high WIP and many of these are reactive tasks. When we talk about each day of work (framed by "what did you work on today") those posts aren't conversations and don't seem to invite conversations (async or otherwise) about delivery, our teams' progress (i.e. Engineering, Partnership, etc.).

There is an opportunity for us to review how we use Geekbot. Specifically, I'd like to suggest that:

• The #team-update channel be used as a "Townhall" for general updates

• Use Geekbot for more fine-grained updates within the different team channels

  • My thinking is that the different teams are each a unit of people with a team goals (defined by their Sprint).
  • The 3 questions have value however, they should be more closely linked to the work that the teams are doing so that they are better able to achieve their team goals. This will help make it more likely that the time can self-organize around the work that needs to be complete by the end of each Sprint.

  I'd like us to be able to get to a decision on this proposal by Feb 14 (1 week from today).

  I invite others to share their perspective on this proposal.

Thanks to @consideRatio for his feedback on this.

[aprilmj]

Interesting! Based on your description, I imagine that each day's Slack looks something like:

Engineering -

• EU people get online, take a look at the board, see Americas people's updates from the previous evening, and chime in on Slack to say which stories they're picking up, offer each other help
• If anyone would like help, there's an open team call or huddle to synch up
• Maybe at the same 3pm-ish time as today, they share a stand down update? That seems to overlap nicely with
• Americas people getting online, looking at the board, seeing EU updates, saying what they'll pick up, etc.
• Repeat the cycle

Other teams are smaller - so would Partnerships or Product look the same? I'm assuming that, as we do today, each team's channel is open for members of other teams to join & either follow or help out.

[yuvipanda]

I'm happy to give any changes a wholehearted try.

A question is whether participation in this is required, given it helps not just you but others in the team. I think it's important to have specific guidelines around this. What are your thoughts on that, @aprilmj and @haroldcampbell?

[aprilmj]

"Required" sounds like something someone else makes you do, and I think of team interaction changes as something everyone needs to agree to wholeheartedly try for a certain time. If the new approach works and fills a need, its existence becomes a social pressure.

(not to make this a semantic argument - agreed vs. required feel like very different vibes to me, but they may feel the same to others)

[choldgraf]

A few quick thoughts from me:

• I'd be fine with not "requiring" things, because we fundamentally want these processes to be useful to 2i2c's team, and it should be on us to either improve systems or communicate their value clearly in order to encourage participation. Or put another way: the lack of engagement in something is a valuable datapoint by itself, and by not "requiring" things, we can shift focus towards "why isn't somebody participating in the way we'd hope? and what can we do to improve it?" in our retrospectives.

  Maybe a better word is "agree and expect one another to engage", rather than "require". I think it's more about our team holding one another accountable to following our agreed-upon practices. It might also mean that over time, sub-teams start to change how these rituals work in order to better-suit their needs.

• This sentence resonates with me:

  The 3 questions have value however, they should be more closely linked to the work that the teams are doing

  I think these processes will be more useful if we can tie them more directly to the work that teams are doing on a day-to-day basis (that's the point). I think that means that these updates should be related to the backlogs that drive each team's work forward. To that extent, "teams that share a backlog" might be a good way to define "subteams" of reports.

• It does raise the question: what about cross-team initiatives? For example, if somebody in engineering wants to ask a question or get action from somebody in partnerships. I think we should ensure there's visibility across teams and the ability to pull people into conversations, even if the updates happen in different channels.
• I am +1 on using #team-updates as a kind of "town hall" or "all hands" place for communication.
• What about the more informal "how is it going?" style updates? Would those also be in sub-team channels rather than #team-updates? I can see arguments either way so happy to go with whatever.

[haroldcampbell]

Following up with a few additional thoughts:

• Yes. Over time it is expected that the teams (i.e. Engineering, Partnership, whomever) would modify the team rituals of work in order to better-suit their needs

• To that extent, "teams that share a backlog" might be a good way to define "subteams" of reports.

@choldgraf In the context of the Engineering team, are you implying two different subteams (Americas vs Europe) for example? Or did you mean something else?

• Regarding dealing with cross-team initiatives, I think this will continue to evolve until we find a natural way to communicate outcomes. I don't see an issue with people having access to different channels or being able to ask questions directly.

• Regarding #team-updates being renamed or being rebranded. Let's hold-off on this change until after we've gone through a few rounds of Team Retrospectives. There is a fair amount of change fatigue presently.

• What about the more informal "how is it going?" style updates? Given our size, we can leave that in the #team-updates channel.

[haroldcampbell]

[won't fix] @choldgraf and @aprilmj I'm going to put this on hold for the moment. There isn't an appetite from the teams to change their ways of working to have these types of check-ins.