Caseflow: NEW STANDUP NORMS ๐Ÿ‘

Created on 24 Apr 2017  ยท  12Comments  ยท  Source: department-of-veterans-affairs/caseflow

There were some concerns last retro about standup not being useful, or there being ways we could improve it. Here are my rough notes:

  • know more about specifics of how things are going in standup
  • standups are supposed to talk about blockers
  • investigate different formats for standup
  • many people don't have context on what other people are working for standup to be useful
  • peoples mind is on how to report their own thing rather than listen to how they can help others
  • possibly each person doesn't talk as much during standup? (just talk about blockers)
  • experiment with online standup tools?

Add your thoughts here and we will discuss after standup on Wednesday!

Outcomes

  • allow designers to pass
  • reassess how valuable it is for designers to be there
  • review your in progress issues personally, but only say important things about your tickets, you don't have to talk about all of them.
  • 5-10 min full team (and optional full team discussions), 5 min sprint team huddle (or other post-standup convos)
  • keep invalidation as is. But maybe be a little more choppy about it.

Most helpful comment

I think that the full-team standup provides value for handing out unassigned work, and for announcements that truly concern everyone.

What if we do the following format:

  1. Team-wide announcements, led by @shanear or whomever is driving

    • "Git got messed up last night. You may need to pull from X".

    • "Welcome this new person to the team"

    • "We're going to make a new advance team to do discovery on Y; talk to me if you're interested in that."

  2. Distribution of unassigned PRs / tickets
  3. For each person:

    • Do discuss:



      • Work that affects the whole team





        • "I'm changing the linting rules"



        • "I'd like to switch from npm to yarn; let's discuss after standup"



        • "This ticket I'm working on affects the styleguide"





      • Blockers





        • "I need help with component X โ€“ does anyone have particular experience with it?"



        • "I haven't been able to test condition Y because the data isn't set up right โ€“ can someone help me with that?"





      • Relevant announcements





        • "I'm on PTO on Friday"






    • Do not discuss:



      • Status reports that don't require action from anyone or are obvious from the standup board





        • "As you can see from the board, I'm working on issue #X and reviewing PR #Y."



        • Assumption: people are organized enough to know when PRs are assigned to them, or if they're not, they can be pinged offline to remind them.






    • It is acceptable and encouraged to say "pass" if you don't have anything to say that fits the criteria. It doesn't mean you're not doing work.

Then, each subteam could have their own more in-depth standup if they wanted to. For instance, on Whiskey, some days I'd like to have a more detailed conversation about what order we'll merge our PRs, or how the designers and devs can sync up. This conversation is helpful to us but useless for the rest of the team. We could have this quick sync (no more than 10 minutes) right after standup, and anyone who wanted to listen in for additional context would be welcome.

All 12 comments

I think that the full-team standup provides value for handing out unassigned work, and for announcements that truly concern everyone.

What if we do the following format:

  1. Team-wide announcements, led by @shanear or whomever is driving

    • "Git got messed up last night. You may need to pull from X".

    • "Welcome this new person to the team"

    • "We're going to make a new advance team to do discovery on Y; talk to me if you're interested in that."

  2. Distribution of unassigned PRs / tickets
  3. For each person:

    • Do discuss:



      • Work that affects the whole team





        • "I'm changing the linting rules"



        • "I'd like to switch from npm to yarn; let's discuss after standup"



        • "This ticket I'm working on affects the styleguide"





      • Blockers





        • "I need help with component X โ€“ does anyone have particular experience with it?"



        • "I haven't been able to test condition Y because the data isn't set up right โ€“ can someone help me with that?"





      • Relevant announcements





        • "I'm on PTO on Friday"






    • Do not discuss:



      • Status reports that don't require action from anyone or are obvious from the standup board





        • "As you can see from the board, I'm working on issue #X and reviewing PR #Y."



        • Assumption: people are organized enough to know when PRs are assigned to them, or if they're not, they can be pinged offline to remind them.






    • It is acceptable and encouraged to say "pass" if you don't have anything to say that fits the criteria. It doesn't mean you're not doing work.

Then, each subteam could have their own more in-depth standup if they wanted to. For instance, on Whiskey, some days I'd like to have a more detailed conversation about what order we'll merge our PRs, or how the designers and devs can sync up. This conversation is helpful to us but useless for the rest of the team. We could have this quick sync (no more than 10 minutes) right after standup, and anyone who wanted to listen in for additional context would be welcome.

Pretty much agree with everything you proposed @NickHeiner. I like the idea of more in depth convos with only the relevant parties right after standup, these conversations should be called out in larger standup so the relevant parties all know the convo is happening (the relevant parties don't always fall neatly along sprint team lines)

+1 everything Nick said

  1. how about: https://github.com/binaryberry/seal

  2. I kinda feel like I'd want to be on every team's standup just to have perspective of "stuff that's coming your way." Which is currently the biggest value I get from standup at this moment (since pretty much every team's issues/PRs are somewhat relevant to what I will be looking at).

  3. Would we need to more liberally use the blocked label or add some kind of "less official" discussion label for things to be addressed in standup?

@kierachell

  1. Using an online/async status tool would mitigate one of the biggest benefits to standup, which is to have everyone in the same place to facilitate in-person discussion.

  2. I agree. There are a lot of issues with each swim lane having a separate standup. I think the current leading thought is that we'd reduce the time of standup via @NickHeiner's suggestions, and you could know which post-standup conversations were relevant to you.

  3. Good question. I think the way we have been doing it is fine. It's still valuable to look at everything you have "In Progress" to make sure nothing needs to be talked about or requires anyone else's help. But you shouldn't have to report verbal status on each issue if it's not necessary.

A couple more notes on my thoughts about standup:

Assumption: people are organized enough to know when PRs are assigned to them, or if they're not, they can be pinged offline to remind them.

This is not a sound assumption to make in my experience. PRs and issues get forgotten about all the time and standup is a good time to tease out what we should do with them while everyone is present. (In my experience, almost everyone including myself is vulnerable to forgetting/infinitely postponing issues)

Also, we run a very management light team. In lieu of that, each team member must do a lot more self managing. People have varying degrees of proficiency with this, and it helps some members of the team to have 15 min every day where they can talk through what they are doing with the team. Having seen what the team was like when we had Tues/Thurs standup, to everyday standup, this has a very significant effect.

My point 1 was more as a suggestion for status checks if teams want to have their own standups

And I agree: on some level, it's the point of standup to "poke" you about things that you have on your plate - how many times have we heard the phrase "oh! I have a PR! Ok, I will look at that" at standup?

how many times have we heard the phrase "oh! I have a PR! Ok, I will look at that" at standup?

๐Ÿฆ€ ๐Ÿฆ€ ๐Ÿฆ€ ๐Ÿฆ€ ๐Ÿฆ€

Relating to Nick's point 3, it could be helpful to report out by advanced team to reduce switching from product to product, instead of in alphabetical order. Open to thoughts about how those who span teams could report out - wouldn't want this suggestion to cause repetition.

This is not a sound assumption to make in my experience.

how many times have we heard the phrase "oh! I have a PR! Ok, I will look at that" at standup?

๐Ÿผ ok, well if that's the reality, then we should work with that. But I think it would be a good growth area for people to be organized and self-sufficient, where we can mentor people to be that way. :smile: For instance, I have a github query I keep refreshing to show me all opened issues that are assigned to me.

I also am in favor of in-person standups above slack-based tools. If nothing else, it's nice to be able to look your teammates in the eye once a day and get a read on their emotions.

  • allow designers to pass
  • reassess how valuable it is for designers to be there
  • review your in progress issues personally, but only say important things about your tickets, you don't have to talk about all of them.
  • 5-10 min full team (and optional full team discussions), 5 min sprint team huddle (or other post-standup convos)
  • keep invalidation as is. But maybe be a little more choppy about it.
Was this page helpful?
0 / 5 - 0 ratings