4 ms·

Blockers are not always obvious. People don't always realize that their tasks is blocking someone else. Often times when engineers are blocked, they work on a

Blockers are not always obvious. People don't always realize that their tasks is blocking someone else. Often times when engineers are blocked, they work on a lower priority tasks while they wait. Sometimes that is a good thing but other times they get off track. Spending 10 minutes every day resolving the communication and prioritization mismatches early helps deliver software faster. With just weekly meetings, these issues could go unresolved for days.

nitely 7y ago
This assumes people don't communicate when they get blocked, but wait 24hs to announce it in a meeting.
- ansible 7y ago
  Yes, exactly. A lot of people don't do a good job communicating this sort of thing. It helps to have someone else ask you what's blocking your progress.
  - kelnos 7y ago
    I mean, c'mon. We're not children. We're professional developers. If anyone I worked with waited even a day to raise a blocker on an urgent task, I'd think much less of their abilities.
    - ansible 7y ago
      I don't disagree. But sometimes you have to do what you have to do to keep the organization moving forward.
      - kelnos 7y ago
        It's another trade off, though: do you annoy your developers for what I believe is just a slight increase in velocity? While I do know some developers who like (or at least get enough value from to tolerate) standup, I know many more who find them an annoying waste of time. For teams that do standup first thing in the morning, it even makes them want to go to work less. How's that for starting the day on the wrong foot?
  - nitely 7y ago
    Sure, adding meetings that affect the whole team instead of addressing someone's lack of communication is the way to go.
    - em-bee 7y ago
      that meeting is supposed to only take 5 minutes, and it is only to discover the issue, not to address it. addressing the issue happens after the meeting with only the people who are actually involved.
      - nitely 7y ago
        5 minutes or 5 hours, an interruption is an interruption. My ideal day to be fully productive would've no meetings at all. I don't need each day to be an ideal day, just once a week (or more if at all possible). However, when there is an scheduled interruption each day every day, guess what? Also, anything that feels like micro-management will be considered micro-management. A daily meeting to give a status report looks a lot like that.
        em-bee 7y ago
        at the beginning or end of the day? or before or after lunch break? micro-management is if i tell you every single step that you should do, but a daily status-update is not
        nitely 7y ago
        > at the beginning or end of the day? or before or after lunch break? That could work if everyone gets at work at the same time (+/-30m) or if everyone takes lunch at the same time (+/-30m), which has not been the case in most of the companies I've worked for. It'd be better at the end of the day, assuming no one does extra hours, but then it's even less useful or at least it becomes obvious it's all about status-updates. > micro-management is if i tell you every single step that you should do, but a daily status-update is not It's a micro-management enabler. There's no way to know if it's used to pressure someone to deliver, or to do things a certain way, without working in that team. The bottom line is that stand-ups are of very questionable use. There are just better, more effective ways to communicate what everyone is working on, what things are done, and when someone is blocked. i.e: ticket assignments, PRs, sporadic side meetings, asynchronous communication (Slack, emails, etc), etc.
kelnos 7y ago
> Often times when engineers are blocked, they work on a lower priority tasks while they wait. Sometimes that is a good thing but other times they get off track. Not in my experience. Most developers I work with will raise issues in Slack as they come up. That's part of what being an owner of your tasks is about: communicating issues early and often.
- mobjack 7y ago
  Senior developers can work like that, but junior engineers need more managing.
  - kelnos 7y ago
    In this case I think it's the opposite: most junior developers I know are much quick (sometimes a little too quick) to ask for help when they're stuck, while a senior developer's ego might get in the way of raising a flag.

nitely 7y ago

This assumes people don't communicate when they get blocked, but wait 24hs to announce it in a meeting.

ansible 7y ago
Yes, exactly. A lot of people don't do a good job communicating this sort of thing. It helps to have someone else ask you what's blocking your progress.
- kelnos 7y ago
  I mean, c'mon. We're not children. We're professional developers. If anyone I worked with waited even a day to raise a blocker on an urgent task, I'd think much less of their abilities.
  - ansible 7y ago
    I don't disagree. But sometimes you have to do what you have to do to keep the organization moving forward.
    - kelnos 7y ago
      It's another trade off, though: do you annoy your developers for what I believe is just a slight increase in velocity? While I do know some developers who like (or at least get enough value from to tolerate) standup, I know many more who find them an annoying waste of time. For teams that do standup first thing in the morning, it even makes them want to go to work less. How's that for starting the day on the wrong foot?
- nitely 7y ago
  Sure, adding meetings that affect the whole team instead of addressing someone's lack of communication is the way to go.
  - em-bee 7y ago
    that meeting is supposed to only take 5 minutes, and it is only to discover the issue, not to address it. addressing the issue happens after the meeting with only the people who are actually involved.
    - nitely 7y ago
      5 minutes or 5 hours, an interruption is an interruption. My ideal day to be fully productive would've no meetings at all. I don't need each day to be an ideal day, just once a week (or more if at all possible). However, when there is an scheduled interruption each day every day, guess what? Also, anything that feels like micro-management will be considered micro-management. A daily meeting to give a status report looks a lot like that.
      - em-bee 7y ago
        at the beginning or end of the day? or before or after lunch break? micro-management is if i tell you every single step that you should do, but a daily status-update is not
        nitely 7y ago
        > at the beginning or end of the day? or before or after lunch break? That could work if everyone gets at work at the same time (+/-30m) or if everyone takes lunch at the same time (+/-30m), which has not been the case in most of the companies I've worked for. It'd be better at the end of the day, assuming no one does extra hours, but then it's even less useful or at least it becomes obvious it's all about status-updates. > micro-management is if i tell you every single step that you should do, but a daily status-update is not It's a micro-management enabler. There's no way to know if it's used to pressure someone to deliver, or to do things a certain way, without working in that team. The bottom line is that stand-ups are of very questionable use. There are just better, more effective ways to communicate what everyone is working on, what things are done, and when someone is blocked. i.e: ticket assignments, PRs, sporadic side meetings, asynchronous communication (Slack, emails, etc), etc.

kelnos 7y ago

> Often times when engineers are blocked, they work on a lower priority tasks while they wait. Sometimes that is a good thing but other times they get off track. Not in my experience. Most developers I work with will raise issues in Slack as they come up. That's part of what being an owner of your tasks is about: communicating issues early and often.

mobjack 7y ago
Senior developers can work like that, but junior engineers need more managing.
- kelnos 7y ago
  In this case I think it's the opposite: most junior developers I know are much quick (sometimes a little too quick) to ask for help when they're stuck, while a senior developer's ego might get in the way of raising a flag.