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, having everyone in a room (real or virtual) at the same time is more efficient than asynchronous updates. With asynchronous updates, people are in meetings, in the bathroom, not online yet, etc, and you have higher coordination costs.
I've been on teams that have effective standups, and teams that have worthless ones. I know what each one looks like. But for the life of me, what I can't figure out is why some teams have good ones, and some don't.
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.
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, and imo, shouldn't even be called a standup.
>But for the life of me, what I can't figure out is why some teams have good ones, and some don't.
IME it's the level of interaction of product/management/scrum-masters that make the difference. Good standups consist of just engineer focused updates/requests. Bad ones are progress reports and have participation of anyone not actively contributing to the sprint.
> 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 vital information, and keeps people accountable is truly valuable.
However, a good standup requires everyone to put in effort to keep it useful, fast, and on track. If everyone decides that standups are a waste of time, it becomes a self-fulfilling prophecy as the leads have to pull unprepared reports out of each individual, summarize things because people aren't listening to each other, start over because people are arriving late, and so on. 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.
The daily status update has different role for different people (devs, scrum master, tech lead). It might be useless for devs but valuable for scrum master, for example.
The dynamics also depend on # of people involved - the fewer, the more effective.
What we did in my last 2 teams to make standups better:
Team 1: move it from 10 AM to 11h45 (just before the lunch). Advantages: 1) Not stressing out people who are late; 2) Not breaking the work of people who arrive early; 3) Keeping it short - since it's before lunch, it can't last forever because people want to eat.
Team 2: move to slack e-standup. Advantages: 1) and 2) above; 3) Async, so you can do it early, late, or even the evening before; 4) It takes 2 min for each person, not 20 min and you don't have to stare in the floor while your mind is somewhere else; 5) Avoiding "ummmmm whaaat did I do yesterday ummmm let me think" x 10.
>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".
If the purpose of the standup is to tell people what you're working on and not have any detailed conversations, then that's the best argument for making it async that I've heard.
The optimal standup seems to be everyone posts to channel by 10am what they are planning on doing for the day and if they want help. Everyone reads each other's and replies as needed. Done
I agree with some of what you say, but not all of it.
Back when I first switched to a scrum master role, way back in 2013, I was pretty full on with prescribing the purpose of certain ceremonies. The standup was for X, and the sprint planning was for Y, etc. We had built a successful business model around that back then so it wasn't necessarily being dogmatic about agile and scrum, but knowing our recipe for success and sticking to it, so we ran a tight ship that also allowed us to put our feet up and work more sustainably.
I find myself in a similar leadership role now and, perhaps moreso due to us all working from home since the end of February, I've taken a completely different tack. I really appreciate what agile and scrum embody but after several years of doing it and getting comfortable with my own role in that dynamic, I've pretty much tossed the 'rules' out of the window and gone straight back to basics with the original manifesto.
My team now does 'asynchronous standups' but we don't call them standups. If my team wants to jump on a call to chat, I'll be there, but otherwise, a quick check in when they come online and start their workday is more than enough. That could be at 7.30am or 12pm for all I care. It still performs the function of a standup, and it fits the purpose we've given it.
I'm not really interested in selling proper scrum to my team the way I used to, now I'm far more keen to let them self-organise and let their work, their happiness, and their behaviour speak for itself. They always have the option to introduce more process if they want to.
Daily standups for status updates and whatever is – in my experience, 15 years at this point – entirely useless. As a way to shoot the breeze in the morning just to say hi though, it's really effective, especially when remote. I've been working 100% remotely for the past five years, give or take, and if I didn't have those 15 minutes of just shooting the breeze with people I'd never get my water cooler fix. Your mileage may vary, I guess.
it depends. mostly on team size and workstreams. when the team is working at different unrelated things the standup is near to useless and it's used only to micromanage people. if you are a close-knit team working on the same workstream/feature then yes is beneficial even then in my experience daily standups are overkill. most of the time bi-weekly is more than enough
I think you're redefining what a useful standup is, a little bit. I agree with you though, I'd just phrase it as "standups are pretty useless" and "it's good to have people share context what they're doing".
So maybe that's part of the problem, standup means whatever it happens to mean. You could replace the entire title of this post with "context should be shared async".
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.
> 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.
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.
Standups as status-updates is an awful antipattern that turns so many people off agile - and specifically Scrum.
Standups where each person takes their turn and recites the mantra: 'Yesterday, worked on ticket HN-1234. Today, I'll still be working on it. No blockers.' Sure - if that's all you do, do it asynchronously. Please. Preferably by just updating the Jira ticket, not posting it in Slack. Or... just, don't, because apparently this has no impact on what you do.
If all that happens in the standup is everyone shares what they did yesterday, what they're going to do today, and what's blocking them, then... then what? We shared a bunch of information across the team. What are we going to do about it? Is Dave going to change his plan for the day to instead help unblock Karen? Is Peter, now he has heard what Rachel did yesterday, going to do anything different than he just said he was going to do?
Daily standups are best when they are really daily replanning meetings. As a team - look at the goal for the sprint. Is it still the right goal? Are we going to get it done? Did anyone do anything that gets us closer yesterday? Does the plan for what we do today still seem like the right thing to do to get us there? Is anything interfering with our chances of getting there?
Everyone leaves knowing what everyone else on the team plans to do to move things forward today.
In my opinion, standups are useless - asynchronous or not.
Waiting until the next standup to resolve blockers is clearly not efficient.
What I've observed during standups is mostly people staring at the void waiting their turn and a few obnoxious nerds trying to bullshit their way up the hierarchy by talking way too much for their own good.
The best communication I've seen was during brainstorm meetings.
Standups ensure your team cannot achieve anything meaningful. Imagine having a standup at the caltech physics department with Feynman et al. "What did you do since yesterday, Dick?" "Well I sat at my desk and pondered the nature of matter." "Anything blocking you?" "We don't understand the nature of matter." "What are you going to do today?" "Go down to the titty bar and ponder the nature of matter".
>Waiting until the next standup to resolve blockers is clearly not efficient.
Yeah, don't do that. Standups are for teamwide information exchange to surface unknown unknowns. If you have a blocker and you can start unblocking it, don't wait.
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.
Plus, stop with the "here's why" in your titles. I know you're going to tell me what you think, but that doesn't mean that you know THE TRUTH ABOUT WHY something important should be the way you think.
Blockers usually take longer than ~15 minutes to discuss & resolve, though, and because those discussions are definitely not relevant for the rest of the group, they're not meant to be had in the standup. Instead, we think blockers should be discussed and resolved as they happen, instead of waiting for the standup the next day to report on them.
If I have a blocker, and I wait until the next day to bring it up in standup instead of actually doing something about it at the time directly with the parties involved, I'm either working in a massively bureaucratic place, the decision makers are inaccessible, or I'm wasting everyone's time with shyness.
TBH the only time I'd really think it'd be useful to bring up a blocker in standup is if I was throwing someone under the bus for not helping and I wanted to be like "not my fault!". I don't do that, but it seems like the only purpose.
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.
It's true that most daily standups revolve around "The Three Questions," but that's not the point of stand-ups. The point is, every day the team has a forum where it can potentially change course. It's an opportunity to identify whether my plan for the next 24 hours is still valid, in a similar way to how sprint planning lets the team change course for the next 2 weeks. It doesn't solve blockers, true, but it does allow triaging blockers, and helps to ensure that if someone is blocked you don't have no one jumping in to help (or everyone jumping in to help, which is also disruptive).
Most teams I've been on with ineffective standups are usually a group of engineers working on independent work streams, who if they had to help each other wouldn't know how. The teams that have effective standups have a clear team goal, and engineers are willing to stop what they're working on in order to ensure that the most important work is getting finished.
Our team does our stand-ups in Slack, in a separate channel called "#daily-status".
Every morning, each team member posts a short bullet list of the items they are planning on working on that day, along with details about any things they are blocked by. This happens asynchronously as people start working every day, so one person might post their message at 7 am, while another person posts at 10 am.
Any conversation that needs to happen about someone's daily status message happens in a thread under their message. This gives the team and management an easy way to see what each other's intentions are for the day, without a bunch of distractions or bullshit meetings or people's eyes glazing over while someone goes on a side tangent rant for 10 minutes. Instead, the information is quick and to the point.
It's also very common for people to post a summary message at the end of the day to let everyone know what they actually got done (or didn't get done).
Our whole team is remote, and this method seems to work really well for us.
I personally like seeing everybody else on the call and talking face to face. As a manager I get a feel for how the others are doing. I feel chats-only will get rid of that aspect and make things more impersonal. Do you not have face to face calls at all?
At my last remote job we had stand-up twice a week. It was a small team and we rarely had a reason to care what anyone else was working on. We didn't need stand-up at all.
At my current remote job we have DSU, but the format is simplified. Nobody has to say what they're working on because that's info you can lookup yourself on the JIRA board. The team lead/PM shares any important company info if applicable (usually 2 minutes long) then anyone that has blocking issues is free to speak up if they need help. That's it.
Sometimes we go over by 15 minutes or so if someone raises something complex. As the author pointed out this can lead to people not listening, but for me personally that is a good thing. It gives me time to catch up on daily news or disengage from my work for a little bit. It's even better that my DSU starts first thing in the morning, so I get to use that time to let my brain slowly warm-up and get ready for real productive work.
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.
My team has been testing out a hybrid of the two-- we use a slackbot to gather our answers to the three questions before standup begins. Then we use the meeting time to discuss anything that might have come up as a result of the slack posts.
We've really liked it so far. It cuts out a lot of the bad parts of synchronous standup like trying to remember what you did yesterday on the spot, but still leaves us with the opportunity to share ideas in depth when it makes sense.
I think completely going to an async standup right now wouldn't be good at all for our team dynamic. With the whole team remote, standup is the one time a day we're all on a call together. There's a lot of value that comes out of that even if it's inefficient at times.
When I was doing daily standups it could be useful for people to say what they are blocked on and then for someone else to say that they could try to help them. Where it wasn't useful was if the two people tried to solve the issue during the standup while 10 other people were standing around.
My other pet peeve for our standups was that they would not start on time. This was very common when I started on the team. After awhile I would just force the standup to start on time no matter how many people were there, even if I was the only one there :) After awhile everyone started getting there on time. I understood why people would arrive late since we were always starting late. An unvirtuous cycle so to speak.
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.
I have come to believe that Agile is a hoax and Scrum too is a hoax. Standup meeting is a bigger hoax. Anyways, long before I understood this I wrote about why the hoaxes should happen towards the end of the day. http://www.rahul.ws/on-daily-meetings.html
Yes, they're both ways for consultants to make money. Essentially a marketing gimmick for managers who don't know how to run a development department because they were never developers to begin with and they don't trust developers to manage themselves. It's been going strong for 20 years and is probably a billion dollar industry. Just another part of the US scam economy.
I think that relatively often part of the real motivation for standups is to put people on the spot a little bit to create pressure and/or accountability.
You can ask whether that's a good thing or true to the original vision, but if that's part of what someone aims to get out of standups, then that probably requires them to be face-to-face.
I'm not a big fan of seeing negative emotions (shame, guilt, fear, envy) used to motivate employees (especially if it's the only thing in a manager's bag of tricks) but in small doses it can be OK. So maybe it's not ridiculous if part of the value of the standup is the threat of feeling like an ass if you have to say, "Sorry, I basically got nothing done since the last standup."
I totally agree with the idea that teams should remove blockers as they come up. If someone on my team runs into a blocker 10 minutes after the standup, I hope for everyone's sake that they don't wait until tomorrow's standup to say something, if only because being blocked for a whole day is not really what you'd call "morale boosting".
I'm not a huge fan of in-person standups, but if you're going to do them really make sure they're useful and efficient. I worked at a small startup once where the entire company (~12 people) did a daily standup, which meant listening to what the salespeople were doing every day, and then telling them which bugs I was fixing. Overall pretty useless.
Standups must rank in the top 10 most used cargo cult practices in the tech world.
Amazing to watch a good, collaborative idea that was used amongst people who actually like working together on something they sort of care about be distorted into some dystopian mandatory process that literally no one likes or gets value from.
I read a lot of comments say standups are for developers to discuss, for developers to raise blockers, etc.
In my experience, standups are not only for developers. In my current environment, there is always the product manager of the team who is usually updating us with the information he got from the upper levers of the company. There are also QA testers that discuss their progress. We keep it freakishly short. ~15mins for a team of 10.
While I do find my self looking at the void sometimes, other times I'm forcing my self to pay attention to everyone and to be as helpful as possible. What everyone does that, is what makes a team get it right.
- It makes it easier to parse information, reread, and catch things like hey 2 people are working on the same thing.
- Helps catch people stuck/avoiding work as you can see someone on the same task for 5 days, or rotating between 2 to 3 tasks when none are done.
In terms of discussions, questions or post standup followup, a thread tends to get started per checkin which could lead to a meeting. This also creates a good historical trail for when issues come up.
Though I am a huge slack fan, having a channel per project/epic and any conversation had or meeting gets summarized and put back into the chat
1: Social. By seeing my coworkers over video I remind myself that I work with people, not pull requests or comments. Perhaps more relevant these times.
2: Discovery. 2.1: A minute or two to just touch on overall goals can instill team spirit. Sales target hit? No angry customers? Perhaps a complaint. It helps with team alignment 2.2: A quick rundown on how each persons day is looking / what people are working on. Perhaps not for blocking but sometimes it is useful to connect two people and let them follow up post-meeting.
[+] [-] hyperpape|5 years ago|reply
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, having everyone in a room (real or virtual) at the same time is more efficient than asynchronous updates. With asynchronous updates, people are in meetings, in the bathroom, not online yet, etc, and you have higher coordination costs.
I've been on teams that have effective standups, and teams that have worthless ones. I know what each one looks like. But for the life of me, what I can't figure out is why some teams have good ones, and some don't.
[+] [-] jayd16|5 years ago|reply
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.
[+] [-] protonimitate|5 years ago|reply
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, and imo, shouldn't even be called a standup.
>But for the life of me, what I can't figure out is why some teams have good ones, and some don't.
IME it's the level of interaction of product/management/scrum-masters that make the difference. Good standups consist of just engineer focused updates/requests. Bad ones are progress reports and have participation of anyone not actively contributing to the sprint.
[+] [-] PragmaticPulp|5 years ago|reply
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 vital information, and keeps people accountable is truly valuable.
However, a good standup requires everyone to put in effort to keep it useful, fast, and on track. If everyone decides that standups are a waste of time, it becomes a self-fulfilling prophecy as the leads have to pull unprepared reports out of each individual, summarize things because people aren't listening to each other, start over because people are arriving late, and so on. 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.
[+] [-] jakub_g|5 years ago|reply
The dynamics also depend on # of people involved - the fewer, the more effective.
What we did in my last 2 teams to make standups better:
Team 1: move it from 10 AM to 11h45 (just before the lunch). Advantages: 1) Not stressing out people who are late; 2) Not breaking the work of people who arrive early; 3) Keeping it short - since it's before lunch, it can't last forever because people want to eat.
Team 2: move to slack e-standup. Advantages: 1) and 2) above; 3) Async, so you can do it early, late, or even the evening before; 4) It takes 2 min for each person, not 20 min and you don't have to stare in the floor while your mind is somewhere else; 5) Avoiding "ummmmm whaaat did I do yesterday ummmm let me think" x 10.
[+] [-] pathseeker|5 years ago|reply
If the purpose of the standup is to tell people what you're working on and not have any detailed conversations, then that's the best argument for making it async that I've heard.
The optimal standup seems to be everyone posts to channel by 10am what they are planning on doing for the day and if they want help. Everyone reads each other's and replies as needed. Done
[+] [-] ljm|5 years ago|reply
Back when I first switched to a scrum master role, way back in 2013, I was pretty full on with prescribing the purpose of certain ceremonies. The standup was for X, and the sprint planning was for Y, etc. We had built a successful business model around that back then so it wasn't necessarily being dogmatic about agile and scrum, but knowing our recipe for success and sticking to it, so we ran a tight ship that also allowed us to put our feet up and work more sustainably.
I find myself in a similar leadership role now and, perhaps moreso due to us all working from home since the end of February, I've taken a completely different tack. I really appreciate what agile and scrum embody but after several years of doing it and getting comfortable with my own role in that dynamic, I've pretty much tossed the 'rules' out of the window and gone straight back to basics with the original manifesto.
My team now does 'asynchronous standups' but we don't call them standups. If my team wants to jump on a call to chat, I'll be there, but otherwise, a quick check in when they come online and start their workday is more than enough. That could be at 7.30am or 12pm for all I care. It still performs the function of a standup, and it fits the purpose we've given it.
I'm not really interested in selling proper scrum to my team the way I used to, now I'm far more keen to let them self-organise and let their work, their happiness, and their behaviour speak for itself. They always have the option to introduce more process if they want to.
[+] [-] the_gipsy|5 years ago|reply
Either it's a glorified status update, or it's incredibly inefficient compared to just resolving issues on the spot or at appropriate times.
[+] [-] MuffinFlavored|5 years ago|reply
Or for management to track what you are doing and hold you accountable to deadlines and ask why you are late.
[+] [-] mstade|5 years ago|reply
[+] [-] hidiegomariani|5 years ago|reply
[+] [-] mrkurt|5 years ago|reply
So maybe that's part of the problem, standup means whatever it happens to mean. You could replace the entire title of this post with "context should be shared async".
[+] [-] _t0du|5 years ago|reply
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.
[+] [-] PragmaticPulp|5 years ago|reply
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.
[+] [-] mrkurt|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] jameshart|5 years ago|reply
Standups where each person takes their turn and recites the mantra: 'Yesterday, worked on ticket HN-1234. Today, I'll still be working on it. No blockers.' Sure - if that's all you do, do it asynchronously. Please. Preferably by just updating the Jira ticket, not posting it in Slack. Or... just, don't, because apparently this has no impact on what you do.
If all that happens in the standup is everyone shares what they did yesterday, what they're going to do today, and what's blocking them, then... then what? We shared a bunch of information across the team. What are we going to do about it? Is Dave going to change his plan for the day to instead help unblock Karen? Is Peter, now he has heard what Rachel did yesterday, going to do anything different than he just said he was going to do?
Daily standups are best when they are really daily replanning meetings. As a team - look at the goal for the sprint. Is it still the right goal? Are we going to get it done? Did anyone do anything that gets us closer yesterday? Does the plan for what we do today still seem like the right thing to do to get us there? Is anything interfering with our chances of getting there?
Everyone leaves knowing what everyone else on the team plans to do to move things forward today.
[+] [-] stephc_int13|5 years ago|reply
Waiting until the next standup to resolve blockers is clearly not efficient.
What I've observed during standups is mostly people staring at the void waiting their turn and a few obnoxious nerds trying to bullshit their way up the hierarchy by talking way too much for their own good.
The best communication I've seen was during brainstorm meetings.
[+] [-] jeffbee|5 years ago|reply
[+] [-] mdu96|5 years ago|reply
[+] [-] jayd16|5 years ago|reply
Yeah, don't do that. Standups are for teamwide information exchange to surface unknown unknowns. If you have a blocker and you can start unblocking it, don't wait.
[+] [-] ohduran|5 years ago|reply
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.
Plus, stop with the "here's why" in your titles. I know you're going to tell me what you think, but that doesn't mean that you know THE TRUTH ABOUT WHY something important should be the way you think.
[+] [-] mdu96|5 years ago|reply
and point taken on the "here's why"!
[+] [-] jmondi|5 years ago|reply
[+] [-] overgard|5 years ago|reply
TBH the only time I'd really think it'd be useful to bring up a blocker in standup is if I was throwing someone under the bus for not helping and I wanted to be like "not my fault!". I don't do that, but it seems like the only purpose.
[+] [-] jayd16|5 years ago|reply
Why can't the answer be async?
[+] [-] BranigansLaw|5 years ago|reply
[+] [-] chrisandchris|5 years ago|reply
> the best teams actually unblock problems as they come up
Sure, but that‘s (usually) not how the world works and that‘s why we have daily stand-ups.
[+] [-] jkingsbery|5 years ago|reply
Most teams I've been on with ineffective standups are usually a group of engineers working on independent work streams, who if they had to help each other wouldn't know how. The teams that have effective standups have a clear team goal, and engineers are willing to stop what they're working on in order to ensure that the most important work is getting finished.
[+] [-] remmargorp64|5 years ago|reply
Every morning, each team member posts a short bullet list of the items they are planning on working on that day, along with details about any things they are blocked by. This happens asynchronously as people start working every day, so one person might post their message at 7 am, while another person posts at 10 am.
Any conversation that needs to happen about someone's daily status message happens in a thread under their message. This gives the team and management an easy way to see what each other's intentions are for the day, without a bunch of distractions or bullshit meetings or people's eyes glazing over while someone goes on a side tangent rant for 10 minutes. Instead, the information is quick and to the point.
It's also very common for people to post a summary message at the end of the day to let everyone know what they actually got done (or didn't get done).
Our whole team is remote, and this method seems to work really well for us.
[+] [-] eblanshey|5 years ago|reply
[+] [-] deevin9|5 years ago|reply
[+] [-] y-c-o-m-b|5 years ago|reply
At my current remote job we have DSU, but the format is simplified. Nobody has to say what they're working on because that's info you can lookup yourself on the JIRA board. The team lead/PM shares any important company info if applicable (usually 2 minutes long) then anyone that has blocking issues is free to speak up if they need help. That's it.
Sometimes we go over by 15 minutes or so if someone raises something complex. As the author pointed out this can lead to people not listening, but for me personally that is a good thing. It gives me time to catch up on daily news or disengage from my work for a little bit. It's even better that my DSU starts first thing in the morning, so I get to use that time to let my brain slowly warm-up and get ready for real productive work.
[+] [-] ojosilva|5 years ago|reply
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.
[+] [-] modo_|5 years ago|reply
We've really liked it so far. It cuts out a lot of the bad parts of synchronous standup like trying to remember what you did yesterday on the spot, but still leaves us with the opportunity to share ideas in depth when it makes sense.
I think completely going to an async standup right now wouldn't be good at all for our team dynamic. With the whole team remote, standup is the one time a day we're all on a call together. There's a lot of value that comes out of that even if it's inefficient at times.
[+] [-] graton|5 years ago|reply
My other pet peeve for our standups was that they would not start on time. This was very common when I started on the team. After awhile I would just force the standup to start on time no matter how many people were there, even if I was the only one there :) After awhile everyone started getting there on time. I understood why people would arrive late since we were always starting late. An unvirtuous cycle so to speak.
[+] [-] high_derivative|5 years ago|reply
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..
[+] [-] rahulpyd1|5 years ago|reply
[+] [-] Clubber|5 years ago|reply
[+] [-] mdu96|5 years ago|reply
[+] [-] JJMcJ|5 years ago|reply
The manager and project manager are there to glare at anyone who isn't "maintaining velocity".
[+] [-] adrianmonk|5 years ago|reply
You can ask whether that's a good thing or true to the original vision, but if that's part of what someone aims to get out of standups, then that probably requires them to be face-to-face.
I'm not a big fan of seeing negative emotions (shame, guilt, fear, envy) used to motivate employees (especially if it's the only thing in a manager's bag of tricks) but in small doses it can be OK. So maybe it's not ridiculous if part of the value of the standup is the threat of feeling like an ass if you have to say, "Sorry, I basically got nothing done since the last standup."
[+] [-] lukey_q|5 years ago|reply
I'm not a huge fan of in-person standups, but if you're going to do them really make sure they're useful and efficient. I worked at a small startup once where the entire company (~12 people) did a daily standup, which meant listening to what the salespeople were doing every day, and then telling them which bugs I was fixing. Overall pretty useless.
[+] [-] kitotik|5 years ago|reply
Standups must rank in the top 10 most used cargo cult practices in the tech world.
Amazing to watch a good, collaborative idea that was used amongst people who actually like working together on something they sort of care about be distorted into some dystopian mandatory process that literally no one likes or gets value from.
[+] [-] kostarelo|5 years ago|reply
In my experience, standups are not only for developers. In my current environment, there is always the product manager of the team who is usually updating us with the information he got from the upper levers of the company. There are also QA testers that discuss their progress. We keep it freakishly short. ~15mins for a team of 10.
While I do find my self looking at the void sometimes, other times I'm forcing my self to pay attention to everyone and to be as helpful as possible. What everyone does that, is what makes a team get it right.
[+] [-] mharroun|5 years ago|reply
- It makes it easier to parse information, reread, and catch things like hey 2 people are working on the same thing.
- Helps catch people stuck/avoiding work as you can see someone on the same task for 5 days, or rotating between 2 to 3 tasks when none are done.
In terms of discussions, questions or post standup followup, a thread tends to get started per checkin which could lead to a meeting. This also creates a good historical trail for when issues come up.
Though I am a huge slack fan, having a channel per project/epic and any conversation had or meeting gets summarized and put back into the chat
[+] [-] jbergstroem|5 years ago|reply
1: Social. By seeing my coworkers over video I remind myself that I work with people, not pull requests or comments. Perhaps more relevant these times.
2: Discovery. 2.1: A minute or two to just touch on overall goals can instill team spirit. Sales target hit? No angry customers? Perhaps a complaint. It helps with team alignment 2.2: A quick rundown on how each persons day is looking / what people are working on. Perhaps not for blocking but sometimes it is useful to connect two people and let them follow up post-meeting.