Daily standups should be async
cadencework.com
cadencework.com
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.
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.
Maybe agile doesnt quite actually support our needs. Maybe some frequent socialising is a need. Maybe sucking every last second out of our day in the name of productivity while having zero benefit on the true goal is just one huge smell.
Focus on surfacing problems not solving them.
That thinking is an agile smell. Teams choose their own processes.
That's an interesting claim, but has it be proven or even seriously studied? I have an extremely hard time with open meetings talking without any depth about various subjects which I don't care about 90% of them; it might make me space out and at risk of missing the parts that I could actually be interested in or contribute. Plus this cultivate the importance of oral transmission, with informations easily lost and inaccessible for people unable to participate for various reasons. Maybe a good structured IM (e.g. dedicating a chatroom exclusively for that) could make it work better? I think it is important that the medium be the same for synchronous and asynchronous people.
Daily meetings can be extremely useful in context of routine transmission of info, mostly on always the same well-defined topics + a small amount of random very important things. The important infos must be hierarchized, you can not just drop them in the middle of a stream of boring "I continued to develop X yesterday and will continue to do it tomorrow". So on open engineering subjects, some people may like it and that may be effective for them, but I really want to know if this is the majority of people / for the majority of projects / ...
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".
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.
and this is (I believe) the point of stand-ups. Doing this "async" seems at best weird/hard and at worst impossible.
The original post is for a prduct selling async status reporting, which is realy not what stand-ups should be about.
If you want to have a daily status report, by all means do it remotely or async or whatever works best. If you want to synchronize the team, well the most obvious and effective way is to actually bring them together in the same temporal space (remote or otherwise). You don't need to do this for problem unblocking or status updates, but don't tell me you're doing a distributed async status update as a method of team synchronization.
Exactly. Once you've reduced standups to async individual reports, you lose the team communication benefits.
In my experience: Once you lose the team communication benefits, people give it even less thought and energy, so the value continues to decline until the concept is abandoned altogether.
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.
Yes, this is from personal experience.
> 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.
Look at it from a different angle: If you tell people you're thinking about replacing standups with something more efficient, you've tipped your hand that the current situation might be inefficient. Suddenly, people lose interest in participating in the status quo because even management doesn't believe it works, so the quality of preparation and engagement goes down. This creates a self-fulfilling prophecy where the standups become more and more useless over time.
On a similar topic: I worked in a department that tried to adopt a version of Elon Musk's famous "If you're not adding value, walk out of a meeting" rule. The people who hated meetings made it a point to not add any value in meetings, so they could get up and leave as soon as possible. This forced everyone else to have followup 1:1s with the people who walked out so they could be essentially re-capture their required meeting participation.
> Again, this makes no sense unless from their perspective it already is bad and they just need to convince you it is, too.
Two different topics. People can still dislike standups even if they're helpful.
A lot employees are drawn to work concepts that reduce their workload at the expense of their manager's. It's less efficient to make a manager play a game of telephone to spread information around than it is to get everyone together for a 15-minute standup, but if someone thinks they can reclaim those 15 minutes and force their manager to bring them any relevant info, it's a net win. In the real world, this becomes an inefficient and lossy system, but it sounds good if all you see is an extra 15 minutes saved in your day.
Oh, well yeah, if you put it like that you might have a problem. "These processes are for you, if they're not serving the team or if you think something else could work better, let's talk about it and fix it" as a blanket policy for agile policies (which is supposed to be the norm in agile) is another thing entirely.
> On a similar topic: I worked in a department that tried to adopt a version of Elon Musk's famous "If you're not adding value, walk out of a meeting" rule. The people who hated meetings made it a point to not add any value in meetings, so they could get up and leave as soon as possible. This forced everyone else to have followup 1:1s with the people who walked out so they could be essentially re-capture their required meeting participation.
I have a feeling better meeting planning & pre-meeting communication would fix that and let you retain the "walk out if you can" rule, if desired, but it'd probably have to be so good that it'd far exceed the norm for that sort of thing, so yeah, probably impractical most places.
> A lot employees are drawn to work concepts that reduce their workload at the expense of their manager's. It's less efficient to make a manager play a game of telephone to spread information around than it is to get everyone together for a 15-minute standup, but if someone thinks they can reclaim those 15 minutes and force their manager to bring them any relevant info, it's a net win. In the real world, this becomes an inefficient and lossy system, but it sounds good if all you see is an extra 15 minutes saved in your day.
Yeah, that's probably true in some cases. I still think if you're having 15 minute standups and cutting that doesn't reduce total time for the process, that's strange. Though, yes, it might cause your manager to spend a little more time on it, personally—but taking two or three minutes to scan standup messages and make sure followups happened where relevant (most days this ought to be basically no work) seems like team lead stuff anyway, not manager stuff, which can just mean "whichever developer you've told to do that" if you don't have a designated lead (~every developer I've met over age 25 is very eager to do anything that can be described as leadership on a résumé so finding someone to take that on ought to be easy) and I'm not sure why a manager'd need to be involved most of the time chatting with anyone but the lead over standup stuff, and then only if their input's needed to unblock something or bring in someone outside the team who's too far above the lead's "pay grade" for them to do it themselves, which'd usually be a "let's talk after the standup" conversation anyway (though maybe not, I guess, if they're taking more than five minutes flat).
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.
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.
I think that's just low signal to noise. It definitely takes skill and discipline, but it's also a matter of improving habits. Standups were originally a "better habit". There's a cost, though, especially as teams are more distributed (and diverse).
Or, god, worse if it's manager-centric and everyone's listing every little damn thing they did yesterday just to make sure they sound sufficiently busy. Ugh. No one gives a shit (except your manager, if they're bad and letting standups be used this way) do you need anything? No? Then move on.
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
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.
Or for management to track what you are doing and hold you accountable to deadlines and ask why you are late.
Either it's a glorified status update, or it's incredibly inefficient compared to just resolving issues on the spot or at appropriate times.
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.
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.
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.
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.
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.
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.
There are lots of people who benefit from a named manager. Expecting people to self manage who don't really want to is as bad as micro managing people. I know because I f'd this up at least 3 times building my last company. ;)
I think this is the crux of many problems plaguing software development today.
Unless you're at a brand-spanking-new startup or have been handed the keys to an exciting greenfield project, you're going to be on a legacy project. Which means a combination of adding new features to a pile of cruft, or fixing bugs in that pile of cruft.
This is where it becomes problematic: no one stays at a company longer than a year or two. Industry compensation does not work in the favor of the person dedicating years to a single company and/or project. Which means there is a built in don't-give-a-shit factor to every software project today. Not that the rockstar coders of yesterday ever gave much of a crap of the quality of code they left in their wake, but industry incentives turn us all into code monkeys. And if you happen to be the guy or girl that cares and is staying at the company many years, you'll surely witness a parade of ladder climbers come and go and absolutely destroy the quality of your hard work and effort.
I could go on about title inflation, and the fact that only about 1 in 5 devs is, in my book, truly a senior today. But we're way off topic now.
I think people check out in synchronous standups just as much as in async ones. The only difference is if later I'm interested, I can go look it up if it's async.
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.
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.
It should more like: I’m struggling to imagine how so-and-so particle gets the energy to reach the next quantum state. Anyone want to share a blackboard? This is gonna take us about six pots of coffee to solve I reckon.
Boss: Mr. Feynman, can I see you in my office?
What you're advocating for is regular communication, and people being involved in each other's work. Stand-ups c_an_ help with this, but they aren't the only solution, and in my view, are one of the less effective solutions.
Open, unstructured conversion has always been a better way to solve problems and move things forwards in my experience, and stand-ups entirely kill that by having an orthogonal purpose in the eyes of the manager (unless they're in the trenches doing the same work everyone else is, which is rarely the case).
Let your developers have their own standups however they want to do them. Make sure they do meet and discuss, but stay out of it if you're not right there with them helping to solve the problems.
I mean, if your team is entirely dysfunctional I can see how doing this can kick start thinking about how to solve development better. Better than nothing. But this entire thread is basically "you are doing it wrong, this is the correct process". There ain't no process (mostly).
Perhaps its a way to make terrible, unmotivated developers more productive. I dunno. I've been working from home since March, and haven't missed stand up at all. Everything gets done. Conversations that have to happen still happen. Because we take our job seriously and know enough to reach out when we need to (love my current team, small as it is).
Stand-ups done as status meetings rather than as meetings to plan collaboration to resolve issues do that. Unfortunately, Cargo Cult Agile, focussing on ritualistic implementation of the ceremonies of methodologies like Scrum rather than Agile principles, tends very strongly to that kind of standup.
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.
That may be true. But that's also a good way to turn a 10 minute standup into an hour long spitballing session.
Nearly every blocker or unknown that I've encountered could have been better handled by a 5 minute slack chat with the essential people. Which is almost never my entire team, and is frequently outside the people on my team who would not attend standup anyway.
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.
> 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.
You can.
Saying it in the standup is a formal way of putting the burden on the team. Like "I'm blocked by this. I sent out an email yesterday but no one helped." is useful.
And when you have a scrum master external to the team, it's his responsibility to ask on the next day "X was blocked by this yesterday. Did anyone help?" If no one did, there will be a discussion on why not.
As others have mentioned, it only really works if people are motivated to listen during the standup. If they're not, the team is dysfunctional anyway (regardless of whether you have a standup or not).
Also, it's fairly useless if people are working on fairly different things.
But ultimately, the entire reason you have to go to standup and remind people to do their job is because they are not doing their job. It's surprising the number of people that can't be assed to make a simple to-do list and follow through on it and the number of meetings that are necessary to remind them of this fact.
I mean... what is the failure here? Is this not what Jira and the hundreds of other project management systems is designed to do? It's baffling, to say the least.
What standups help with (IMexperience) are situations where you're spending a lot of time on something but it's not really clear whether you're making progress. Maybe someone has dealt with that API before on a previous project and knows you're doomed, or how to help. Maybe someone has a dusty old CS memory that will turn your O(n!) to O(n). Or maybe — and I don't think we should discount the usefulness of this — it just provides reassurance that yes this is a thorny problem, there isn't an obvious alternative you've missed, you're not wasting your time or being stupid. That makes a big difference in morale, and morale makes a big difference in productivity.
Sure, there's some benefit in having a daily status report to your manager who is presumably also at the standup, but that's not the main benefit of a daily standup, IMHO. If that is the only benefit you're getting from it, then sure, cancel the standup.
and point taken on the "here's why"!
Why can't the answer be async?
So maybe there's a scrum master who then takes my "I'm blocked" thing to whomever is blocking me. But... why can't I just ping the person blocking me and escalate as needed?
The whole thing just feels like corporate babysitting to me.
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.
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.
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.
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.
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.
It's wonderful.
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.
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.
Who hates standups? Everyone else, basically.
Really makes you think..
A wise colleague reminded me of this quote: "There's two kinds of people in this world when you boil it all down. You got your talkers and you got your doers. Most people are just talkers, all they do is talk. But when it is all said and done, it's the doers that change this world." Unfortunately, in this COVID age where Zoom after Zoom is accepted and everyone wants to "show their face" as to not get laid off, it's now prime time for the talkers.
Every time I'm involved in a stand-up I feel everyone is pressured to blurt out randomness. Why not allow people to collect their thoughts for the week ahead and put it on paper/Slack/IRC?
Been doing them for over a decade as a developer and lead developer.
But a lot of people make the mistake of following someone's specific "agile" or whatever system for them. Every team is different and should evolve their processes around what works for that particular team.
For me standup accomplishes a lot of great things.
- Let's everyone know what everyone else is doing. Which let's us identify if two of us are working in the same area of code and address how to do so without creating painful merges.
- Let's you know if someone is struggling to complete their work so you can figure out how to address (pair program, training, eliminating distractions for them, etc.)
- Parking lot gives everyone on a team a daily time that everyone else will listen to them and think about their problem or idea.
And my current team does our retros, planning, and any other meeting we can fit in immediately after standup. This compresses our meeting time down since having a bunch of scattered meetings is too disruptive for programmers as they need uninterrupted blocks of time to code during.
This is entirely against the traditional spirit of standup but it works great for my team.
The manager and project manager are there to glare at anyone who isn't "maintaining velocity".
About the only actionable advice I can offer is (a) admit to being blocked async in real time and then (b) use your standup to escalate and highlight where you are still blocked: "as I indicated in my chat/email yesterday I'm having trouble with xyz..."
If even this is unacceptable you're essentially on a team where you are not comfortable or not allowed to ask for help. I'd evaluate the former to make sure it's not your fear of asking for help, and if it's the later, run.
You either need to affect the change you desire or go somewhere this sort of behaviour is not tolerated. If you can't or won't push for allowing people to ask for help, either live with this disfunction or quit.
I'm increasingly convinced that if you 1) have standups, and they're 2) more than the teensiest bit dysfunctional, you've probably got some badly fucked-up processes and attitudes in general. I mean it does not get simpler than a standup, so if you've decided to have them but can't get them mostly-right, then that's not a good sign. Sadly, this may describe most businesses.
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'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.
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.
We also don't really give two shits about status updates. We care more about what people have actually done, which is what we use Cadence for. Most of our updates are something like "pushed a draft PR for X purpose" and not "still working on the same thing yawn".
At my last office gig employing daily standups they quickly devolved into a thinly veiled attendance check combined with a passive aggressive attempt to shame unproductive team members on a daily basis.
It became just another reason for me to never come to the office. At the time I was in a very head-down overworking phase of life and the leadership would turn my participation at standup into a major component in that shaming tool, because I always had a disproportionate amount of things to discuss.
I would honestly be more ok with standups if there was a bit more honesty about what it's for. If management just said "we need some visibility", I totally get that, I just hate how it's being marketed as if it's for my benefit.
I've been a professional developer for about 15 years, so if you multiply it by 15*261 (workdays in a year approximately), then I've been to about 3915 standup meetings. I can't recall a single one where I thought "glad we did that, we might have missed something huge if we didn't have a standup"
Bob: Yesterday I was working on the migration to the Kokomalta framework. I'll keep doing it today.
Charlie: Yesterday I looked at fixing the printing bugs. Today I'll do more bug fixing.
I've worked in different companies, industries, countries and it's always the same stupid thing, some sort of cargo cult practice that achieves absolutely nothing and wastes everyone's time. As a manager if I want to know the status of some project I ask the person, I don't wait until 10am the next day. And if someone is blocked, reach out when you're blocked to whoever can unblock you. That's it. That is actually agile, not that stupid daily ceremony.
The IT world is full of those dumb cargo cultish practices. One I've started noticing is to prefix everything with "as a user" when writing "stories and epics". "As a user, when I click there I want to have a window with that input box and this text written here". Super useful! I know there's a proper way to do it ("as a senior compliance officer, I want a daily report about ABC"), but no one does it in practice.
At some point I noticed that my teammates, including my manager, often are at least as clueless as me, especially when the verbiage becomes a bit too technical. I thought I'd do everyone a favor by simplifying things. So some time ago, shortly after the start of a sprint I tried a format that corresponds pretty much with what is generally understood from our little speeches, but said more directly: "well, I made some progress on that thing yesterday and I'll work a bit more on it today. That's about it." On the second standup of this, my manager asked that we have an impromptu demo that afternoon, which was really inconvenient, since instead of working on my branch, I now had to spend the morning preparing a presentation that he could understand. That's when I realized that daily standups aren't really designed to boost developers' productivity, but another tool that is easily misused by managers to give themselves the illusion of control.
Don't ask me what I think of scrum, it would rhyme.
It was great because first of all there is a history everyone can look back on, which can save some unnecessary communication and coordination. But most importantly it avoids the dreaded sidetrack conversation that turns your standup into a 20 minute meeting.
Because of the confinement my team has switched to async standups to account for our varied work hours (people on kid duty, etc)
There is an ideal balance between fully async and going down a rabbit hole. A good standup will have feedback from others in the group, but it is important for everyone to know and respect time boundaries. One or two sentence interjections usually work great.
When you're giving updates as frequently as daily, a synchronous feedback loop is necessary for the information to be relevant. If I post in a slack channel that I am debugging issue X, and 2 hours later, someone posts that they dealt with X last week and has a solution for it, I've just wasted 2 hours of time.
> In fact, the best teams actually unblock problems as they come up
Maybe I'm reading them wrong, but it seems to me like these two lines are in direct contradiction. Obviously if a problem is a "fire" then yeah, you want to solve it immediately.
But if the problem isn't urgent and can be worked around, why disrupt someone on your team? Overall I think the framework / pattern presented in this post doesn't take urgency or team experience into account -- in my experience, synchronous standups are great and useful for quick discussions of non-urgent blockers, especially when the team is more junior and could benefit from exposure and shared understanding.
> “It’s clear how even though all companies say they “do agile”, in fact most don’t; they just do random meetings while standing up, which produces bad results that I consider right-out offensive towards developers."
So really the daily standup is about progress reports. Which is totally fine, but, yeah, async is just as effective.
It's reasonable to suggest standups and other meetings be async. What would be better is to take the time to design a proposed solution for solving the problem standups solve, even if it ends up being a messy or bad one.
That's a much more effective way to complain about a problem than simply spending words trying to convince people that something is bad.
Offer an alternative. Create debate. Put in the work to solve it.
Let me know if you'd be interested in trying our product out -- seems like you'd give great feedback. My email is melissa@cadencework.com
But that's not what a 'daily standup' is supposed to be and the point is to get people together.
> "It’s clear how even though all companies say they “do agile”, in fact most don’t"
Well, indeed. That's why everything is called a 'daily standup' these days.
I do a form of async stand up at work.
Its mostly progress tracking for my boss.
Never get any feedback. Never share any woth others. (Itried in the beginning)
The real time nature of a standup a d implied time pressure has all kinds of effects that cant be duplicated in a lole for like way.
Im not fully of the belief it cant be adequately substituted im just saying dont call it async standup. It just sounds like youve never used one.
It’s important to strike a workable balance between putting everyone to sleep and unblocking issues quickly.
My idea was that you should not be allowed to speak about your daily task more than 42 second on a video record shared to all you team mates.
> In reality, there's actually no space in the standup to dive deeper into actual issues.
I've never heard of a standup without a parking lot. The entire point of parking lot (and the main value of standup) is to discuss issues with the entire team engaged.
> In fact, the best teams actually unblock problems as they come up, instead of waiting for a regularly scheduled standup to report on a blocker.
So, instead of having a scheduled time when everyone is available. You want to make decisions disrupting everyone in the middle of their day and not having their full focus?