4 ms·

In my experience, async standups mean everyone posts their status and does not read any other status. Counterpoint: In my experience, at synchronous standups,

In my experience, async standups mean everyone posts their status and does not read any other status. Counterpoint: In my experience, at synchronous standups, people totally ignore everyone until its their time to speak, and then share an update, and then go back to not listening.

mrkurt 6y ago
Those sound like relatively useless statuses then. Getting people together doesn't increase inherently increase the usefulness of updates, although sometimes it helps by accident since people ask questions. When it works, it's just painting over bad management.
- alexbanks 6y ago
  Daily standups are not a solution to people not caring about what their peers are doing, is my point. You can't make people care, even if you make them show up.
  - mrkurt 6y ago
    Oh yes I agree. I would argue that "making standups async" is a good way of discovering management/team related issues. What tends to happen instead of the no-true-scotsman fallacy. If standups aren't working (they probably aren't) you must not be doing standups properly.
PragmaticPulp 6y ago
> In my experience, async standups mean everyone posts their status and does not read any other status. That has been my experience, too. Going async sends a message that people don't need to care about what their team members are working on. That's a dream come true for the people who just want to pull Jira tickets out of the queue, finish them in isolation, and then collect a paycheck. However, it doesn't make for great team cohesion and knowledge sharing. Teams end up compensating with extra meetings and coordination overhead, which starts to defeat the point of async standups.
- alexbanks 6y ago
  I'm _very_ disillusioned by blaming lots of software process as a bailout for bad devs. I dislike most software process (agile), but I think some of the processes defined by agile are mostly just branded common sense. Talk to your team. Give a shit about what they're doing. Care about your work. Care about your project. Sometimes heavily scrutinized, reasonable process doesn't need to be modified. Sometimes the devs do.
  - the_other 6y ago
    > Talk to your team. Give a shit about what they're doing. Care about your work. Care about your project. If you go to the original agile manifesto, it’s basically just this. It’s consciously against packaged, branded solutions. I’m fond of Scrum. The most coherent and comfortable jobs I’ve had used Scrum. Also one of the worst (in terms of productivity) tried it too. It seems to me that the overall system can be a problem, but it wont be the whole story. Sometimes the client/product/management sides of things lead to counter-productive work. Sometimes developers silo themselves, or think too much about their code and not enough about the product & users. Sometimes the product sucks. It seems to me the hardest bit is defining, scoping and agreeing the units of work, appropriate to the size of team and aims of the product. If you get this wrong, the product will suffer. It takes some input from everyone to get this part right, and you can make it work with any system, branded or not. It’s just hard. I’m not saying you need reps from all departments in all your meetings, I’m saying you need everyone to work within and around the framework in a way that gets the product made. EDIT: type.
  - mrkurt 6y ago
    I think it's more frequently a bailout for bad management. Either because a manager sucks, or a team can't self manage.
    - alexbanks 6y ago
      Maybe I'm taking "Bad management" to literally mean "Bad managers", when people mean "the process of management"? Is a team that cannot self manage not (for software teams) a dev problem?
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]

mrkurt 6y ago

Those sound like relatively useless statuses then. Getting people together doesn't increase inherently increase the usefulness of updates, although sometimes it helps by accident since people ask questions. When it works, it's just painting over bad management.

alexbanks 6y ago
Daily standups are not a solution to people not caring about what their peers are doing, is my point. You can't make people care, even if you make them show up.
- mrkurt 6y ago
  Oh yes I agree. I would argue that "making standups async" is a good way of discovering management/team related issues. What tends to happen instead of the no-true-scotsman fallacy. If standups aren't working (they probably aren't) you must not be doing standups properly.

PragmaticPulp 6y ago

> In my experience, async standups mean everyone posts their status and does not read any other status. That has been my experience, too. Going async sends a message that people don't need to care about what their team members are working on. That's a dream come true for the people who just want to pull Jira tickets out of the queue, finish them in isolation, and then collect a paycheck. However, it doesn't make for great team cohesion and knowledge sharing. Teams end up compensating with extra meetings and coordination overhead, which starts to defeat the point of async standups.

alexbanks 6y ago
I'm _very_ disillusioned by blaming lots of software process as a bailout for bad devs. I dislike most software process (agile), but I think some of the processes defined by agile are mostly just branded common sense. Talk to your team. Give a shit about what they're doing. Care about your work. Care about your project. Sometimes heavily scrutinized, reasonable process doesn't need to be modified. Sometimes the devs do.
- the_other 6y ago
  > Talk to your team. Give a shit about what they're doing. Care about your work. Care about your project. If you go to the original agile manifesto, it’s basically just this. It’s consciously against packaged, branded solutions. I’m fond of Scrum. The most coherent and comfortable jobs I’ve had used Scrum. Also one of the worst (in terms of productivity) tried it too. It seems to me that the overall system can be a problem, but it wont be the whole story. Sometimes the client/product/management sides of things lead to counter-productive work. Sometimes developers silo themselves, or think too much about their code and not enough about the product & users. Sometimes the product sucks. It seems to me the hardest bit is defining, scoping and agreeing the units of work, appropriate to the size of team and aims of the product. If you get this wrong, the product will suffer. It takes some input from everyone to get this part right, and you can make it work with any system, branded or not. It’s just hard. I’m not saying you need reps from all departments in all your meetings, I’m saying you need everyone to work within and around the framework in a way that gets the product made. EDIT: type.
- mrkurt 6y ago
  I think it's more frequently a bailout for bad management. Either because a manager sucks, or a team can't self manage.
  - alexbanks 6y ago
    Maybe I'm taking "Bad management" to literally mean "Bad managers", when people mean "the process of management"? Is a team that cannot self manage not (for software teams) a dev problem?

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]