If what you call a 'daily standup' is a status meeting where each dev reports to the team lead/manager then sure it can be async and that would indeed be more practical.
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.
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.
Communicating blockers in stand up should be for heads up purposes. Just to let everyone else adjust expectations on your work. If you’re waiting for a stand up to kick off resolving a blocker, that doesn’t seem right.
> Am I the only one who raises a flag immediately when there is a blocker? Why would I wait until the next day?
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.
They're not mutually exclusive. Especially at a time when everyone is remote and it's easy to miss emails/slack messages, etc., having a dedicated time to say "Hey all, I'm still waiting on X" is helpful.
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.
In my experience, the "blockers" that standups help with are not so clear cut. Of course if I reach a point where I clearly can't proceed without X, I'll email/slack/async-request the person who might be able to get me X, and work on something else until that resolves.
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.
I think about it like this — if I ask a question, someone needs to be interrupted to make that happen. Even if they were on slack anyway, or between tasks, if it’s not something they are otherwise working on, it may take them off their task. If my thing is critical or blocking others, I raise a flag. If it can wait, I wait too. Disruptions are probably one of the most costly time investments of our trade.
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.
The OP confused the issue significantly, IMO, by suggesting that “let’s take this offline” was a bad thing. NO it’s half the point! Identify the blockers, identify who can help, and take the solutionising elsewhere. Also, as you say, solve the blocks as they happen. You still need the stand-up to replan now you’ve used up X amount of unplanned time unblocking something. This might impact delivery.
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.
yeah, I don't get it. If you need someone's attention, make it your task to get their attention. In my experience, I'm rarely blocked by someone else on my team, so saying I'm blocked in standup is like complaining about work at the bar- maybe it feels good but it's kinda useless.
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.
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.
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.
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.
Agile is smelly. People getting blocked in a team small enough for a standup is a concerning smell. Bad standups are a smell, and also seem to be the norm.
I suspect all these smelly meetings might be an agile smell itself.
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.
I have had low value standups with groups of just three developers or six developers, so I don't think that's enough. I agree that the feeling of "I have to justify my work to an external party" is a negative.
Literally had a manager say "oh, they're supposed to be for unblocking? I just thought it was an easy way for me to report up the chain on what my team is working on, that's why I told people to just write it on Slack to make it easier for them." ugh
Stand-ups becoming a status report to justify your employment is a common end state of “going agile”. Meeting gets longer, people add more trivial minutiae, nobody wants to look the laggard
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.
> Stand ups should solve the problem of "I need to get unblocked and I can't get my teams attention effectively".
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 / ...
Standups always bored the shit out of me because a huge fraction of time is spent listening to irrelevant stuff. I wonder if speed dating might be more stimulating.
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".
> 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.
>> having a well-run standup that synchronizes the team
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.
> The original post is for a prduct selling async status reporting, which is realy not what stand-ups should be about.
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.
> 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.
> What the hell? Have you actually seen this happen?
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.
> 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.
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).
As an IC, I've honestly just not attended many (any?) standups that provided value to me. I understand if it's for someone elses benefit, but that someone else is most assuredly not me.
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.
> 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.
It might fall under "non-functional team" but active listening/reading of usually banal but sometimes critical information is simply not an easy thing to do in a routine format. The information in a standup is team-wide because you do not know what will be important to who. It takes some amount of skill and discipline from the team.
We 1000% agree on this, but it's still fun to talk about.
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).
Part of this is because the standard format encourages including shit that no-one cares about, or that a glance at the issue tracker or repo activity would (should...) clarify immediately if anyone wants to know. If your "no blockers" updates could be written by a very simple script maybe don't bother with those parts.
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.
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
>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
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.
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.
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.
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.
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.
Daily standups are not a solution to people not caring about what their peers are doing, is my point. You can't make people care, even if you make them show up.
Oh yes I agree. I would argue that "making standups async" is a good way of discovering management/team related issues.
What tends to happen instead of the no-true-scotsman fallacy. If standups aren't working (they probably aren't) you must not be doing standups properly.
> 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.
I'm _very_ disillusioned by blaming lots of software process as a bailout for bad devs. I dislike most software process (agile), but I think some of the processes defined by agile are mostly just branded common sense.
Talk to your team. Give a shit about what they're doing. Care about your work. Care about your project.
Sometimes heavily scrutinized, reasonable process doesn't need to be modified. Sometimes the devs do.
> 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.
Maybe I'm taking "Bad management" to literally mean "Bad managers", when people mean "the process of management"? Is a team that cannot self manage not (for software teams) a dev problem?
I definitely mean "the process of management". A team that can't self manage is just a bad team. You can have a lot of great people on a bad team, so I don't think it's exactly a dev problem. It's a "whoever puts teams together" problem.
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.
Holding a daily standup sends the message that people aren't expected to be talking to other people on the team regularly, and actively requesting help when they need it. 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.
I don't think the issue is team cohesion, but rather level of detail. I'm generally interested in what my coworkers are making, but in the sense of "I want to see a demo of it when it's ready". I really don't care about "Y: wrote DB migration script, T: waiting on design." That kind of thing is neither useful nor interesting if I'm not their manager.
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.
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.
IME (both as an IC and as a Manager), daily standup is the tech worker equivalent of a time clock. Most developers won't be in office until 1 minute before the daily standup.
> In an ideal world, daily stand-ups are meant to unblock problems and help teams ship product faster. In reality, there's actually no space in the standup to dive deeper into actual issues. The second you do, everyone else tunes you out, your standup drags on much longer than it needs to, and you're asked by your manager to "take it offline".
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.
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.
yeah that's a really great point -- how standups are most useful when the people in them are working closely together, and especially not useful when the people aren't working closely together (e.g. like you and the salesperson).
What's this thing with blockers? I'm not in software and it seems like they're just problems you encounter that need to be resolved before you can continue working? Why not go to your co-workers desk or message them and deal with it on the spot?
For me the daily standup is a chance to be debriefed by the project manager so that they can convert my updates to actions in JIRA. It's what liberates me from having to personally interact with JIRA. In that sense the standup is worth its weight in gold no matter the format.
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.
- 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
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.
Ugh, similarly, in one of my previous jobs we had a guy that was underperforming (I don't know why, he seemed smart, but it wasn't working out). Every day the standup turned into like 10 minutes of management and management lacky's bullying the guy and treating him like a child. It must have been awful for him (one day he just quit with no notice), but it was incredibly uncomfortable for the rest of us too -- I definitely didn't want to start my day every day with a long conversation about how this guy wasn't getting his work done.
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"
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.
That seems cool, but we haven't really needed anything fancy. As engineers, we are always trying to build solutions and over-complicate things, but sometimes all you need is for some people to just agree to do something (like posting a status message), and then everyone needs to hold each other accountable like adults.
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?
There are still a lot of zoom/tuple/phone calls going on between people (in an asynchronous manner, as needed). We also do weekly retros as a team on a group call.
We use Cadence for Fly.io, mostly because standups are useless for us. We're small enough that we don't have external blockers, and we expect people without external blockers to just ... not get blocked.
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".
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".
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.
Next day: well, I drank too much coffee, and I'm burned out on socializing from brainstorming all day. I still don't know how so-and-so particle gets the energy to reach the next quantum state, and honestly I just want my coworkers to shut the fuck up for a few days so I can focus.
I agree with what you've written, but this isn't an argument for stand-ups.
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 chat with people all the time when I'm looking for a creative break out. The idea that it is just going to happen at 10:30am on a daily schedule is baffling to me.
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).
> Standups ensure your team cannot achieve anything meaningful
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.
I would agree that a lot of my greatest breakthroughs came from periods of time that felt like, to me, I was just staring into space waiting for my brain to kick out something useful, and I would have no idea when that would happen. And if it something that is going to stop everything, I can fiddle around commenting code and doing bits that require little thinking as I wait for inspiration to strike, but it seems to show up on its own time.
>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.
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.
People will jump down your throat: "well, you're not doing it right!" but what you're stating is a true and hard problem that's deeper than any process can address.
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 thinking about asking to sit (haha) in or call into a standup, next place I look at, after I have an offer but before I take it. If there's even a hint of this kind of toxic shit I'll know to run, fast. If the manager I'm talking to is like "well I guess we can arrange that, but they're usually under five minutes so there's not much to hear, and I'm not in them so I'll put you in touch with [team lead or maybe project manager] who runs them" then that'll tell me what I need to know without even bothering.
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.
I enjoy the daily stand up. Sometimes single digit minutes, sometimes it goes on for half an hour. It is the opportunity to sync with the team. Questions get asked, priorities may be revisited, any new concerns can be voiced, and we all leave with the shared knowledge of what we are all working on today and if there is room for us to help one another. The live aspect of it allows a check point where things can be pivoted live. "Oh, I missed your question in slack, let's talk about it right after this meeting."
Our stand up is a daily thread in slack. Totally painless and useful. Very often they lead to better collaboration and cutting off duplicate work before it really starts. FWIW I work on a small team at a very large company. Possibly that’s the sweet spot for stand ups like this. As typically someone on our team will make someone else aware of work another team has done we can leverage.
Stand ups mostly exist to remind you that you need to be present at work at an early time of day during a core part of the week. It's an efficient tactic of making sure people get their asses into chairs week in and week out.
155 comments
[ 3.0 ms ] story [ 109 ms ] threadBut 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.
Because of the confinement my team has switched to async standups to account for our varied work hours (people on kid duty, etc)
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.
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.
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.
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.
It’s important to strike a workable balance between putting everyone to sleep and unblocking issues quickly.
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.
- 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
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"
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.
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".
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.
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.