Live data from Hacker News

Daily standups should be async

cadencework.com

61–70 of 156 posts

Re: Daily standups should be async

#61

I think if your standup can be async, then it's ineffective, and you should get rid of it. And to be clear, that's fine! Not every team needs standups. The only value in a standup is when team members actually share ideas about what they're working on. The detailed conversation happens outside the standup, but the purpose of the standup is just to get that moment of "I know about that, let's talk". In that case, havi…

> I think if your standup can be async, then it's ineffective, and you should get rid of it. I agree, with one caveat: If you tell engineers that standups can go async or be cancelled if they're ineffective, they will find creative ways to make the standups ineffective. Poorly run standups are bad. Standups where the engineers are half-engaged are bad. But having a well-run standup that synchronizes the team, spreads…

> If you tell engineers that standups can go async or be cancelled if they're ineffective, they will find creative ways to make the standups ineffective.

What the hell? Have you actually seen this happen? I can't imagine someone jettisoning something that makes their work-life easier and is an extremely low time commitment, just because you tell them they can. I can imagine them changing it to something else if that's more useful and cheaper, time-wise, or getting rid of it if it's of very low utility. Lots and lots of standups are the latter, from the IC's perspective. A lot of "talk to the manager who's the actual audience for the meeting, everyone else dozes off" standups. "Ten people and only two others are actually on my project, and we talk all the time anyway". That kind of thing. Plenty of that out there. I could see them wanting to get rid of those. I mean if people are putting so little effort into the standup that it makes them bad, and the standup is for them, supposedly, then maybe that's a sign it isn't valuable to them?

> If you tell people the standup can go away if it's bad, you've accidentally incentivized those people to make it bad enough to get it cancelled.

Again, this makes no sense unless from their perspective it already is bad and they just need to convince you it is, too.

Re: Daily standups should be async

#62
Working intensively remote during this pandemic, we rediscovered an old practice of ours we call "comm-work". Basically we share screens (on Zoom) while talking about whatever is going on at work. It's sorta of a "open-space" equivalent but online and with a mute button.

Comm-work is more about showing than telling. A screen is always shared (or a whiteboard). We share emails on screen and sometimes write them together, we hear in into a customer call (like through Teams whilst we remain connected through Zoom), or we just tune out into our thing. It's an impromptu that can last anywhere from 20 to 90 minutes.

It's not scheduled, it's not a standup, you don't have to report status (yuck!) or say anything. Just keep working if you feel like it. You can mute yourself or others. Most of our teammates (not all teams are the same) feel like sharing something, be it a milestone, a cool widget they found or a piece of code they feel are blocking. This works great because it just naturally surfaces issues before they are issues.

The bad part, if anything, is that it is run by a manager who knows how to improvise, when to call one up (and call it off if someone has to take their kid to the doctor) or how to dig into the team's mind and create the meeting narrative. It also requires some degree of direct speak ("Hey you, whats up with that task?") which also does not work with every ego around. So this is not something that I think can be taught at seminars as it's not very scientific. It's just natural and basically arises whenever a chat room becomes to chatty. I personally believe comm-work is deeply more effective than any agile standup or kanban, which never ever worked for us. Being such an improv keeps people on their feet. They never know when the team is going to meet, what the next customer email will say. Your code editor becomes not so much of a secret place. I know it sounds almighty corny, but screen sharing is the ultimate sharing at a workplace.

Re: Daily standups should be async

#63

Working intensively remote during this pandemic, we rediscovered an old practice of ours we call "comm-work". Basically we share screens (on Zoom) while talking about whatever is going on at work. It's sorta of a "open-space" equivalent but online and with a mute button. Comm-work is more about showing than telling. A screen is always shared (or a whiteboard). We share emails on screen and sometimes write them togeth…

We do something almost exactly like this to generate draft content. People get on Zoom, screenshare, and then we get notes down for what we can create from it. It's a little less improvisational because we start with an idea for an article and see where it goes.

It's wonderful.

Re: Daily standups should be async

#64

You know who likes standups? Program managers, project managers, and useless middle-managers. What do they have in common? They get to exercise power and justify their existence through calling extra meetings like new project-specific standups. Who hates standups? Everyone else, basically. Really makes you think..

I think this is more or less true. Present them as a tool to your team. Walk them through it for a week or three, maybe. If they don't want to keep doing it then one of 1) they don't want/need them, or 2) you have been bad at running/presenting standups, and in either case you don't need to be pushing them on the developers anymore.

Re: Daily standups should be async

#65

I think if your standup can be async, then it's ineffective, and you should get rid of it. And to be clear, that's fine! Not every team needs standups. The only value in a standup is when team members actually share ideas about what they're working on. The detailed conversation happens outside the standup, but the purpose of the standup is just to get that moment of "I know about that, let's talk". In that case, havi…

I disagree. Obviously if they're async we should please stop calling them "standups" but they can still fulfill some of the goals of a standup.

You want a way to voice your status, hear other's statuses, hear blockers, and reduce duplicated effort. You can do all this with short, daily, async updates. The synchronous fashion of the standup is mostly a factor of verbal communication, not a feature.

Standups are usually partially async as items that arise should be dealt with outside of the meeting.

It still needs to be daily and time gated such that the team can consistently read everyone's status.

Forcing the team to pay attention is probably harder in an async conversation chain than a meeting but I don't think ineffective is correct.

Re: Daily standups should be async

#66
post #5

The whole purpose of daily standups is to be short, to the point, and force developers to discuss blockers. That can't be async, because I need the other members of the team to answer. The issue the author is addressing is that for some, this is wasted time. But a) that's why these meetings are short, thus the standing up part, and b) Usually it isn't but an opportunity for more seniors to chime in with suggestions.…

This makes sense for developers, but what about BAs and product owners that then have to attend 3-4 stand-ups a day? This seems like a nice way to give them a high-level view of what's going on, as well as for the rest of the team.

Re: Daily standups should be async

#67

Earlier quoted context omitted.

> 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…

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…

> 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.

Re: Daily standups should be async

#68
post #65

I think if your standup can be async, then it's ineffective, and you should get rid of it. And to be clear, that's fine! Not every team needs standups. The only value in a standup is when team members actually share ideas about what they're working on. The detailed conversation happens outside the standup, but the purpose of the standup is just to get that moment of "I know about that, let's talk". In that case, havi…

I disagree. Obviously if they're async we should please stop calling them "standups" but they can still fulfill some of the goals of a standup. You want a way to voice your status, hear other's statuses, hear blockers, and reduce duplicated effort. You can do all this with short, daily, async updates. The synchronous fashion of the standup is mostly a factor of verbal communication, not a feature. Standups are usuall…

> Forcing the team to pay attention is probably harder in an async conversation chain than a meeting but I don't think ineffective is correct.

I think this is a feature. If people aren't paying attention to asynchronous information, there's a problem. Either the information isn't useful or the team isn't functional.

Re: Daily standups should be async

#69

I think if your standup can be async, then it's ineffective, and you should get rid of it. And to be clear, that's fine! Not every team needs standups. The only value in a standup is when team members actually share ideas about what they're working on. The detailed conversation happens outside the standup, but the purpose of the standup is just to get that moment of "I know about that, let's talk". In that case, havi…

Agreed. Async stand ups are an agile smell. If you can successfully get unblocked async over slack/email/whatever, there isn't a need a for standups. That just means you have a functioning line of communication for your team. Stand ups should solve the problem of "I need to get unblocked and I can't get my teams attention effectively". If async "standups" solve that, great. But it's not a one size fits all solution,…

The unblocking in a standup is almost always async. They're there to have a defined place for public knowledge transfer. You usually shouldn't drag down the standup with a prolonged conversation. You can take care of it after in an async way even with in person standups.

Focus on surfacing problems not solving them.

Re: Daily standups should be async

#70

Earlier quoted context omitted.

> 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…

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…

I think it's more frequently a bailout for bad management. Either because a manager sucks, or a team can't self manage.
Post reply on HN