4 ms·

> I disagree with the author on the point of standups - they're not big-picture strategic sessions; they're about short-term, tactical planning. What work are y

by sidlls 5y ago

> I disagree with the author on the point of standups - they're not big-picture strategic sessions; they're about short-term, tactical planning. What work are you going to do today? Are you blocked by anything? This has always been my problem with standups: they feel a bit too much like micromanagement.

tharkun__ 5y ago
This may have been due to how your standup worked. Believe me I have seen it too and part of why I want to be a team lead/scrum master is to make sure this does not happen to my team. Did your standup feel like a report to the Product Owner? Or a report to the Scrum Master? Or a report to Team Lead? Not good. Creates the feeling you had. The standup should create conversation between team members. 'Oh you said you are doing X while doing your tasj? That won't work for my Y, good thing you mentioned it, let's have a quick talk after standup' As a scrum master if they 'report status to you' you can for example not look them in the eyes all the time so that they can't fixate on you. There are ways to still show them that you are paying attention. If the PO is asking follow-ups that make it clear he's expecting status reports to him you can take him aside and talk to him about that. It might come to the point where you have to threaten to throw him out of standup if he doesn't shut up and then he won't even be able to even listen. Same goes for team lead depending on whether you have a separate scrum master or maybe the team lead has that hat.
- sidlls 5y ago
  > The standup should create conversation between team members. A team of even adequate--not great, just adequate--people working together will have these conversations independently. > 'Oh you said you are doing X while doing your tasj? That won't work for my Y, good thing you mentioned it, let's have a quick talk after standup' There are two different cases where this would apply: when someone attempts to do something and finds some blocking issue, and when someone attempts to do a task out-of-order from a dependency. The first case rarely occurs in a way that a daily standup will efficiently address. Most tasks take longer than a day to do--the standup is unlikely a time when this sort of issue is most efficiently resolved. Other than junior engineers or maybe quick bug fixes I rarely encounter an engineer who measures his work by the time between standups. The second case is best resolved by having a proper, complete design process--requirements analysis, technical design (changes in architecture, code, dependencies, etc.), and a team-wide review--and a work tracking tool that permits tasks to be ordered (e.g. JIRA's "blocked by" label). Work doesn't always fit into that neat of a design and execution process, obviously, and it's okay to have an occasional, regular meeting (e.g. once a week or every other week, maybe slightly more often depending on the scope of work the team typically has) to address those specific issues as-needed. But those meetings shouldn't be permanently scheduled on the calendar--just while a given project is in progress.
  - theshrike79 5y ago
    > A team of even adequate--not great, just adequate--people working together will have these conversations independently. Then the daily standup will be really damn fast. =) On the other hand the daily is a place where you _know_ that the other person isn't busy and it's a good time to raise any concerns or ask for assistance.
    - marcosdumay 5y ago
      Fast meetings do not exist. Once the time is allocated, if there's nothing of importance to discuss then some low value subject will always fill it.
    - sidlls 5y ago
      If it's going to be "really damn fast" because nobody has anything (more) to say, it's pointless (and micromanagement, for the managers' benefit only). And if the person is busy, they should indicate as much. People shouldn't have to have a carve-out on their calendar for concerns or requests for assistance: that's an indication of a dysfunctional team.
      - theshrike79 5y ago
        My fastest scrums have went like this (on $chat_application): <scrum master> anyone have anything new for daily? <dev1> nope, still working on $task <dev2> nope <tester1> nope, still finishing up testing $task2 <scrum master> let's skip it then
  - forgotmypw77 5y ago
    >A team of even adequate--not great, just adequate--people working together will have these conversations independently. And nobody else will know about them.

by sidlls 5y ago

tharkun__ 5y ago

This may have been due to how your standup worked. Believe me I have seen it too and part of why I want to be a team lead/scrum master is to make sure this does not happen to my team. Did your standup feel like a report to the Product Owner? Or a report to the Scrum Master? Or a report to Team Lead? Not good. Creates the feeling you had. The standup should create conversation between team members. 'Oh you said you are doing X while doing your tasj? That won't work for my Y, good thing you mentioned it, let's have a quick talk after standup' As a scrum master if they 'report status to you' you can for example not look them in the eyes all the time so that they can't fixate on you. There are ways to still show them that you are paying attention. If the PO is asking follow-ups that make it clear he's expecting status reports to him you can take him aside and talk to him about that. It might come to the point where you have to threaten to throw him out of standup if he doesn't shut up and then he won't even be able to even listen. Same goes for team lead depending on whether you have a separate scrum master or maybe the team lead has that hat.

sidlls 5y ago
> The standup should create conversation between team members. A team of even adequate--not great, just adequate--people working together will have these conversations independently. > 'Oh you said you are doing X while doing your tasj? That won't work for my Y, good thing you mentioned it, let's have a quick talk after standup' There are two different cases where this would apply: when someone attempts to do something and finds some blocking issue, and when someone attempts to do a task out-of-order from a dependency. The first case rarely occurs in a way that a daily standup will efficiently address. Most tasks take longer than a day to do--the standup is unlikely a time when this sort of issue is most efficiently resolved. Other than junior engineers or maybe quick bug fixes I rarely encounter an engineer who measures his work by the time between standups. The second case is best resolved by having a proper, complete design process--requirements analysis, technical design (changes in architecture, code, dependencies, etc.), and a team-wide review--and a work tracking tool that permits tasks to be ordered (e.g. JIRA's "blocked by" label). Work doesn't always fit into that neat of a design and execution process, obviously, and it's okay to have an occasional, regular meeting (e.g. once a week or every other week, maybe slightly more often depending on the scope of work the team typically has) to address those specific issues as-needed. But those meetings shouldn't be permanently scheduled on the calendar--just while a given project is in progress.
- theshrike79 5y ago
  > A team of even adequate--not great, just adequate--people working together will have these conversations independently. Then the daily standup will be really damn fast. =) On the other hand the daily is a place where you _know_ that the other person isn't busy and it's a good time to raise any concerns or ask for assistance.
  - marcosdumay 5y ago
    Fast meetings do not exist. Once the time is allocated, if there's nothing of importance to discuss then some low value subject will always fill it.
  - sidlls 5y ago
    If it's going to be "really damn fast" because nobody has anything (more) to say, it's pointless (and micromanagement, for the managers' benefit only). And if the person is busy, they should indicate as much. People shouldn't have to have a carve-out on their calendar for concerns or requests for assistance: that's an indication of a dysfunctional team.
    - theshrike79 5y ago
      My fastest scrums have went like this (on $chat_application): <scrum master> anyone have anything new for daily? <dev1> nope, still working on $task <dev2> nope <tester1> nope, still finishing up testing $task2 <scrum master> let's skip it then
- forgotmypw77 5y ago
  >A team of even adequate--not great, just adequate--people working together will have these conversations independently. And nobody else will know about them.