But it works great for us. We have explicitly discussed it before and that’s how we want it, at least for now.

The thing is, it’s a completely remote team of 9 people (two PMs, two engineering managers that code, 5 developers). 5 of us never met in real life and the rest were remote even before the pandemic. For us developers it is the only group meeting in the day 90% of the days. The PMs and Managers have lots of meetings, so they are often the ones leaving the standup early, and that’s ok.

We want that meeting to be loose, to allow for non-work conversations, to be flexible in what and how each person share their status. It works great for this team, of this size, with these people.

That’s the thing with advice like the OP. You have to make assumptions about how teams behave. But teams behave in an infinite combination of size, members, companies, and time (we might decide a year from now that we want to run standups differently).

This is what makes standups shitty. I couldn't care less to know if you are still working on something. When you are done working on it, I'll know because the tooling will let me know of the changes. There is no time where vocalizing this provides value, unless you have no tools at all, which seems pretty silly if you are not working with a team of prehistoric cavemen.

If you have a fun story about what you did last night, a recap of last night's reality TV show, whatever floats your boat – that's much more valuable use of the time. I can get behind that, although don't be upset if I don't always show up.

If that's all anybody ever says, then I'd agree. But, in practice, with my team, there might be one person with nothing much to report, but several others who needs assistance, want to demo something they've built, are ready to transition something to QA, or something else. If you aren't getting any of that in your stand-up then the team is "broken" and could likely use an open conversation about the meeting's purpose and value.

If it gets said at all, you should also agree. If the goal if your standup is simply to hear people talk, talk about what you did on the weekend instead. That will actually provide value to the team in building a better relationship with teammates. "I did X yesterday, I will do X today" provides no information potential or bonding potential. It is flat out worthless.

More realistically, if all you have to say is "I did X yesterday, I will do X today" it is best to not say anything at all. The goal shouldn't be to hear someone speak, but rather to achieve a business objective. Sometimes people won't have anything to contribute towards that objective and that's okay. Other times they will. They can speak then.

Team meetings can be beneficial. Having the team meet so that they can utter practically-gibberish canned messages to each other is not beneficial. On the bright side, I see (from the parent comment and many others) that we have finally dropped the equally useless "no blockers" routine. We're making progress here!

But, in practice, I'd prefer somebody gave a little more context than a simple "working on X" (assuming X isn't trivial - if it was, you would have finished it already) - what part of X... Design? Coding? Testing? Any roadblocks? Do you expect to turn it over to QA today or tomorrow? Nobody is working a vacuum and all our work intersects at some point.

Assigning turns so that someone is forced to spit out that gibberish is nonsensical. Allowing someone the floor when they speak up when they have something to say is worthwhile, and something people do naturally. There is no need for an explicit turn where someone must say something.

> Regurgitating a, what is little more than gibberish, canned response when you have nothing to say is very different to speaking when you have something of value to say. That it only takes 10 seconds to utter that gibberish does not give it any more value.

I can't tell if there are two people on your account? Maybe you two should chat.

They technically could, but usually they are smart enough to realize that it is stupid to do so and reserve the act for when they know they have something of value to contribute.

If you are hiring stupid people, well, good luck. Someone uttering gibberish is likely the least of your worries, which no doubt explains why you haven't noticed the problem with it.

I never mentioned a canned response they were told to say. You've invented this.

That you seem confused about the subject now is... strange.

[0] https://i.imgur.com/3uyRWGJ.jpg

The purpose of a functioning standup is contextualization. If you know your teammate is still working on feature X, maybe you notice that your own work is related and you can design some shared data structure that speeds up both of you.

If you want to be an IC with no responsibility, that's fine, just make it clear to your team that your assigned work is all you are going to do. If you want to be more productive individually and as a team, though, the interconnectedness of the team is just as important as what any one member is working on.

I'm still not clear on what information ”worked on feature X yesterday. Will continue to work on feature X today” gives me.

It gets better if there's some detail about the task, like "Still working on X, runtime is too slow but I found a paper linked from Wikipedia with a promising algorithm." Lots of inferred and implied knowledge transfer can happen through intetactions that seem simple on the surface. E.g. in my example here, ideas of how to approach research for a task, what kinds of obstacles are normal, etc.

If you're not building camaraderie, then maybe your standup isn't set up right or at the right time, but that doesn't mean the concept or the information is useless.

And as a last resort, if you can't change something, then put in your own effort to make the best of it instead of just wasting the time entirely.

Oh, but I can change something. If you remember having this discussion last year, it was ”worked on feature X yesterday. Will continue to work on feature X today. No blockers.” To which I pointed out that the "No blockers" part serves no purpose as if anyone had a known blocker, they would have already let the team know when it became a blocker, not wait for a fixed time of day. It is not coincidence that the last part isn't said today.

Today, I am here to share that the rest of the canned response is also useless.

Build camaraderie. Actually talk about the work you are doing with your teammates. These things can be beneficial and you'll still get the same non-verbal cues if there is something afoot. Don't waste valuable time on nothingness.

1. If I did, I would have told you a long time ago when it became a blocker.

2. If I somehow forgot to tell you a long time ago, I would have told you when I did my standup comedy^H^H^H^H^H^H routine.

3. If I still somehow forgot after all that, it doesn't matter.

I also have trouble getting back into the flow of where I was, but I think 30 minutes would be my max lost productivity.

Of course that is in addition to all the other costs that come with standups. For example any fixed daily meeting kills the possibility of flexible working hours. That is one of the top perks for many developers and some developers are also much more productive working at non-traditional times.

The standup meeting can also feel like an inquisition, particularly for juniors or new starters. It doesn't even have to be the classic manager-holding-court effect, just whoever is leading the meeting having a bad day and speaking in the wrong tone. Again, there goes your productivity for that person for possibly the entire rest of the day.

If anyone reading this does use daily standups and everyone on their team wants to then that's great. Every team is different and doing what works for your team is what matters. But personally I have found that while sometimes useful points do arise during standups the benefits are greatly exaggerated. Valuable insights and awesome collaborations do not happen anything like often enough to justify all the downsides of the meetings, not least because IME the same information would probably have been passed on some other way and often faster in any moderately functional development team anyway.

Now every where I go some douchebag paranoid manager has established daily stand-ups because it makes them feel better. I resent telling people I'm working on a story we all groomed together and brought into the Sprint....it's right on the board: In progress, In Review, Ready for acceptance, Done. Clear as day. I'm still working on X, gonna work on X some more...everything is going great. Not adult-like behavior.

Given how common standups seem to have become, that probably tells us something. Maybe the typical daily standup as widely advocated isn't usually productive and it's actually some variations used by some individual teams that have been more worthwhile for those specific teams?

Fundamentally, that is also the idea pushed in software. A chance to talk about what needs to be done that day. But, in my experience, tech companies also schedule planning meetings. That is where it is determined what will be done for the next while (two weeks seems to be a common cadence) and after that the course is set. There is nothing else to talk about, unless someone has a problem, and when someone has a problem (assuming your team is functional) they reach out when they have a problem, not wait until a prescribed time 23.75 hours later.

That means there is no additional information to give in the standup, and thus this is likely the source of why standups end up being pointless the vast majority of the time in tech. The healthcare case, on the other hand, provides clear value.

There are likely some cases where tech teams suffer from no direction, void of an idea of what needs to be done before the moment it needs to happen. I imagine that overlaps with tech that is dysfunctional. A productive standup does not exactly seem like something to strive for, but if all you have is a bandaid...

I feel your assessment of 30 minutes to build the universe in the purest sense is fair, but I'm not sure it accounts for the additional friction involved. You might be the exception, but humans in general are known to avoid building up the universe, so to speak, if they anticipate an interruption. It takes even more time for the mind to accept that the time is right.

And so, all told, I think two hours is quite reasonable.

https://www.washingtonpost.com/news/inspired-life/wp/2015/06...

What a gem. Whenever the next "silicon valley" is made I'm waiting for a character to say this. Simply hilarious.

Get off your high horse. You can afford an interruption or two per day.

Standup can be great if the responsibility across the team are spread out, but only at a lower frequency (once a week?).

Fine, catch me the moment I wake up. But good luck finding two team members who wake up at the exact same time each day. That never happens in the real world. No matter how you slice it, productivity is going to be destroyed.

I like it for two reasons, I go for lunch straight after so don't have two context switches. And it sometimes works as an effective midday target for me to try to get a ticket progressed before the standup.

Asynchronous standups avoid that problem, but I've never seen an async standup bring any engagement and ends up being nothing more than "I'm working on X again. Duh." which is completely pointless.

In fairness, as you are forcing a context switch for a standup, it is likely that you do work with unreasonable people.

It was glorious. Having record of all conversations for easy reference really did help build better software, as far as I am concerned. These days, everyone wants to do video conferencing, it seems, and half the time the job doesn't get done right because someone misheard something or forget what was said. It makes no sense to me.

I can only imagine that those who think voice communication is the best communication haven't tried anything else.

If you have to put forth effort to keep the standup interesting, you are admitting that the people see no value, which means that you are meeting just for the sake of meeting. If you see value in meeting just for the sake of meeting, why not talk about what you did on the weekend instead?

We do it similarly to how you describe here -- we have a short intro (5 mins) before diving into each of us presenting. Each of us presenting may take 2 mins or take 30 mins. If one of us is struggling or blocked, we use this time to collaborate + pair program/debug.

Eventually, we get through everything and then go about our day. Sometimes (because I am the "lead"), I'll use the opportunity to ask questions about roadmap or other items that I need their input on. They're already distracted and not "in the zone", so chaining on the additional "meeting" works quite well.

Because of this, these are our only meetings every week. We get a bit of "water cooler" chatting in, we are able to unblock each other, and we are able to have a short iteration loop for re-prioritizing our work. (New tasks can be delegated by quickly going through the backlog)

The pandemic has really changed work, and I really feel like we're still iterating on what the best dynamics are for teams to be productive. Thanks for the insight into your team dynamic!

0: https://github.com/lunasec-io/lunasec

1: https://agilemanifesto.org

Process should always be owned by the team as a whole. It should also be ever improving (even if this means complete change) and, almost more importantly, you should have as little of it as possible (it shouldn't get in the way).

I get it, not all are morning people. Please mute your mic, I really don't want to hear you yawn half a dozen times. It's obnoxious. If you're talking and you need to yawn, just mute for a second.

I know you're still working on this ticket (what's the point of JIRA otherwise?), just tell me if you need help on it or are blocked. That's more important to the team.

Standups over zoom or as a dedicated meeting are honestly a waste of time when people show up late or yawn just to go over mostly the same status every day. Just post your update in slack, let others know if you have any blockers.

I'm pretty much checked out these days, so I don't really care. What should be a 5 min exercise (90% of the time) turns into 20 minutes of pain. Others enjoy it as it is though, so I don't really care. Also every other meeting is similar nowadays too, way too lax and people seem to be okay being slow/lazy.

This is why I prefer standups to be right before lunch (back when you'd have lunch with your coworkers). People are awake and have a reason to not want things to drag on.

Of course, when one of your coworkers is on the west coast (and the rest are on the east coast), it's not lunch time for everyone, but it still tends to go quicker than if the meeting was an hour earlier.

For a time I was managing a team that used this PO, and I quickly banned him outright from standups. Told him to keep his guidance granularity at the sprint level, make sure his stories were written well enough to not require constant elaboration, and otherwise leave the developers alone. He could show up for sprint review & planning. Standups were just to unblock anyone who needed it, and should only last a couple minutes.

He also liked to take really shitty notes, then treat them like the gospel truth. I read my stand-ups from notes I'd written beforehand—never done that anywhere else, but the amount of crap one was evidently expected to talk about was large enough there, that I did, after the first week or two—so I could tell for a fact when he'd recorded something about mine that was flat-out wrong, and it was often.

There are other routines that are actually helpful but don’t feel like the red guard roll call.

The reason it is called standup it was because the meeting was literally done standing, the idea was to force people to talk as quickly as possible whatever needed urgently and make them leave because they are tired of standing in one place.

What you are doing is some kind of daily meeting, but not a standup in any sense.

We used to have huddles at work, but it didn't mean that we were actually nestled closely together for warmth.

What made the meeting not-standup is the fact the meeting is not short. The fact people take time to talk about their daily lives, and other random stuff, means it is not a standup meeting.

I mentioned the original standup meeting was standing, because the point of it was force people to want to leave the meeting.

Paraphrasing, you said the reason it’s called a standup is because people are literally standing, to force people to talk quickly.

Then you said because of this OPs meeting wasn’t a standup.

But appreciate that isn’t what you intended.

More people work remote now, it's not 1995 anymore ( history of scrum). As most things, scrum evolved. It's a guide, not a strict protocol/law

The idea is to have all the technical things in one time to eliminate interruptions later on, not to eliminate personal connections with the team. So what is a better time for the casual talk, since people don't have coffee breaks anymore? ( If everyone of the team is onboard fyi)

I kinda miss in person with the entire team. I see some people seriously slacking and those are the ones not really involved with casual talk too ( coincidence? ).

While many people are perfectly able to work remotely, it made the job of a eg. teamlead much harder to confront more difficult things. They can't notice the body signals anymore when a person's cam is just off ( and even then).

I think he's meeting 99% of the idea behind a scrum standup, except for standing up. So for some reason the lack of physically standing up reverts the 99% to 0%?

This whole concept seems silly, to be honest. It seems like it's designed to pull out status updates from people who wouldn't otherwise participate and wouldn't ask for help on their own, but at a set schedule.

If I'm blocked, then i might as well drop a message in the group channel or eventually tag specific people who i think could help me. Or some people just choose to PM me directly.

The only worth that I'd get from a meeting with everyone together is actually talking about details that might be interesting: "Last week i ran into a race condition in the code, here's what it was, here's how i solved it and here's how to avoid them in the future," in lieu of discussions like that in the chat channel.

As a developer, i don't care if person A is working on X, Y and Z or is blocked, if i cannot help when with any of those. If management needs status updates, we might as well automate them with "Standup & Prosper" (https://standup.teaminator.io/) or a similar chat bot that gives you fields to fill out. Even freeform daily messages seem more reasonable than forcing everyone to do some silly ceremony.

Now, here's my question to you: what am I missing?

Since we're fully remote, and we do standup over voice, we only see each other via video a couple times every three-week iteration. So a little chatter at the beginning of standup is a way to just check in and see how people are doing, including in their personal life.

Another idea to perhaps add: we've informally agreed that the time right after standup is typically reserved for small group discussions for any subset of the team.

We're fully remote (and have been for 10 years), so when standup starts, our brains have already shifted to "talking" mode (rather than planning/coding/reviewing mode), so it's easy to just keep going and help talk through any issues that would benefit from synchronous communication. Sometimes we screenshare, but frequently not - we just talk through whatever we're stuck on or could use insight from others.

This happens with us as well. Usually for technical discussions that will take longer than 5 to 10 minutes.

And that's the key: Do what works for your group.

The problem is that we have middle managers and project managers and middle project managers who go to conferences and watch lectures online and hang out in social media echo chambers talking about the latest, greatest innovation in managing projects without thinking about the people or the tasks involved.

Too often development teams are forced to work for the process, rather than the process working for them.

I've been in places where the PM would say things like, "We'll do it this way because it's what Google does." Well, Google has seventy brazillian people, and we have six on our team. What makes PMs think that one size fits all? It doesn't.

I currently have a guy who's trying to impose a project management method he learned from a video game company on us. We work in healthcare. But he refuses to deviate from what worked for the video game company, and thinks it's OK for the users to "discover" features on their own, rather than letting us spend time documenting how the system works. Again... in healthcare.

I spent a good few minutes trying to understand this sentence. Mainly because I am Brazilian and was stunned how did you know that I was. Then trying to understand how the number of Brazilian people might affect standup dynamic. Then trying to understand exactly how many Brazilians there were in Google and how many of the six of your team were Brazilian. Just then I understood it was an expression for “a lot” hahaha

Feels like it's probably been positive for people since we all went 100% remote March 2020.

Good team rapport and trust etc are important factors, it's vital no one is "scared" to give honest updates.

My favorite version is one in which we just went through the daily Merge/Pull Requests in the system and let that be the check in. It set aside regular time for small code reviews and let everybody showcase things clearly, with room to ask people to dive in for a deeper review right then and there.

IMO it was much more effective than the normal standup ritual.

We want most of our meetings to be effective, but we're intentionally about that one being a bit "sloppy". It's a good time to get to know people and uncover challenges that people might not raise asynchronously otherwise.

Before agile and standups were the hip thing, the norm in all places I worked was to have a weekly team status meeting. Those were great. Weekly is about the right cadence for this type of meeting. It gives you four days to deep dive into technical work without worrying about status reports all the time. With a week, you end up having something meaningful to talk about and listen from others.

That seems so fantastical to me :/. That works out to 1 day with other group meetings every 2 weeks. Glad to hear there are places like that though!

This is the real key, IMHO. As a manager, I push the team to figure out what works best for them. I've seen daily standups w/status reports, no standups where we simply message the details, and bi-weekly where we talk more about status and challenges and save "what I did" for other mediums. In all cases, it's what the team wanted and worked best for them.

Those chit-chat conversations are important and since they weren't happening by accident we made it part of the structure. I also encourage people to turn their cameras on during standup, just so we see each other once a day.

Slightly off topic, but I realize this is a subject I'd be interested in reading more about. Would be interested in suggestions in the same vein as Creativity, Inc. by Edwin Catmull?

Made me feel close to people I only knew remotely.

Because your standup is primarily providing team bonding and meets other emotional needs.

The biggest problem is that managers can easily fall into a trap where they have everyone in the same place so they can ask individuals questions that only really matter to them. Beyond about 8 people (and maybe as low as 5) this means a bunch of people are standing around while other people give updates on things they don't really care about. I've seen standups with 20 people that last 45 minutes as the manager goes around the room, basically. That's not a standup.

It's even worse if PMs and other non-eng are there. Just, stop.

This brings me to my second point: size. Standups need to be small. No more than 4-5 people ideally. In an office environment these people should be in a pod of 4 desks (possibly minus the EM and/or TL who might have broader responsibilities) and they should be able to turn around and talk to each other, at which point you don't really need a standup anyway.

But I can't tell you how many times some EM has triggered crisis mode due to impending deadlines and we end up spending an hour a day with 20 people in a "standup" until the situation improves.

What seems pretty universal is the amount of information i share nobody cares about and the amount of information other people share that i don’t care about are both quite high.

It serves as an opportunity to be bored and frustrated for a half hour each day and does a rather good job of interrupting my daily flow.

I think a key to a needed standup is a small group of people actually working collaboratively on something whereby the shared information is actually good to know.

I am though a fan of short meetings of any topic where you literally are standing for the meeting, it seems to change the quality.

Yesterday, I asked a team member if they had QA'd my project. They said, "oh I wasn't expecting to QA your project."

Yet I told them in the standup that I needed them to QA the project and I tagged them in a story. Clearly paying attention...

During standup, I've also had people say "colmvp, you can go next" despite having already spoken.

And near the end, we often don't even remember who hadn't spoken.

I feel like standups work well for small teams, but in larger teams it just feels like it becomes impersonal and more of a thing to do to make yourself appear obedient to your manager.

After all that there are still more architectural discussions, meetings to clarify stuff. And then we break interfaces every other day. Reason given is "way of the agile". I can't speak in general, but it seems that we couldn't design a solid software for the long run if our lives depended on it anymore.

I wonder what kind of processes industries like aviation, defense, and other high stake industries have?

Lots of up front planning in great detail with timelines and details dependencies. Lots of understanding how schedules slip. Some space systems go to the levels of planning for a number of bugs and if the result is off high or low, it is a matter for investigation.

Also, no daily meetings (unless culture has changed since I was inside a while back).

The most important things are an advanced method of requirements generation and change management.

It seems like almost everyone in the software industry is just making shit up as they go along which is... themed to the right way to do things but not actually doing it. Cargo cult processes.

I can confirm that the big management consulting firms are selling modified "agile" processes to the MIC and the US military itself. I suspect that means they're selling them to most large orgs with that sort of culture.

I don't know whether they're complete bullshit and don't actually mean much as far as how things actually operate—hopefully that's the case. If it's actually changing anything and not just shuffling around some names for processes, I assume it's making things worse.

> "The most important things are an advanced method of requirements generation and change management."

Makes perfect sense seeing how those wrecking havoc in far simpler software I'm working on. Thanks very much for sharing.

It is absolutely useful when you're doing a 10 billion dollar project with dozens of contractors when your customer is say, the Army.

The way I've seen all of these things done in commercial software is like middle managers heard about requirements in an elevator while drunk and went home and decided to implement them. i.e. nobody know at all what they're doing, and they're trying to accomplish something they've heard of but never come close to experiencing done well.

I feel the same way about Agile. It came from the way a group of smart effective people worked together and decided to share... it's being implemented almost everywhere by people who are looking for a set of guidelines to follow and don't at all grok the point of any of it.

That's just this season's excuse. How often have we seen some change that is obviously going to make things worse for a lot of individuals being justified because it's supposed to foster better team communication and so make the overall unit more productive? Open plan offices, frequent meetings, ever shorter cycles for everything, ever less up-front thought before diving in, real-time messaging on all the time, etc.

I wonder how many of today's developers, including the relatively senior ones, can even remember how productive you can be if you work out a clear brief with whoever else needs to be involved and then you are left alone to concentrate on doing the work for a while, where "a while" means at least a half-day and possibly several days.

I'm not a 'process guy' though so I have no idea what to replace these things with, if anything.

https://www.pivotaltracker.com/help/articles/terminology/

> The Icebox panel contains stories that have not yet been prioritized. If you want to add a story and keep it “on ice” until you’re ready to prioritize it, click the + Add Story at the top of the Icebox panel. When you’re ready to prioritize the story, drag it into the Current or Backlog panel. Icebox stories are in the unscheduled state.

It's even worse if PMs and other non-eng are there. Just, stop."

A lot of managers or PMs really can't be allowed into a standup. Especially if they show only from time to time and take over the meeting.

1) If the team was like, "our team on this project is tiny and we all sit next to each other, so we don't need them", or "we'd rather do Slack messages for standups, on this particular project", he'd let that happen without a fuss, aside from ensuring that any communication he needed from it was still, somehow, happening. So it was still team-driven and very flexible.

2) He was very disciplined about not turning them into project status meetings, or making standup messages take the form of status updates.

[EDIT] I should add that the benefit to him was that he got to hear a lot of unvarnished truth about what was going on, which micromanagers don't get, because he was at all times, in the face he presented to the team, on "our side". That put him in a much better position for polishing up the information he had for consumption outside the team(s), which benefited us, too. He might have questions or something, and it's not that he never pushed back on anything, but he let standups be standups, and kept that stuff separate and as non-confrontational as possible.

I do not understand the mindset that goes into thinking that somehow a person is 1. Not required for a meeting and so can only attend on occasion and 2. If present must drive the entire thing.

I guess in theory they might think they are improving things if they assume it is an unguided, unfocused disaster with out them, but in my experience it is the exact opposite: a focused, relevant, quick stand up without vs a meandering, drawn out, ritualized boilerplate, "explain to the PM stuff everyone else knows" meeting with.

PMs can be genuinely useful too. They just need to use the most important words in their toolkit: "you 2 (3,4) discuss offline/afterwards, next person". Not to be used if people are casually chatting, but to fix that problem of 2 people having a conversation while 6 others listen for no reason.

Edit: this is some bullshit inspired by rugby where you have regroup and change strategy as you learn about your opponents, what does that have to do with developing software I don't know.

In practice, it turns out that you don't normally learn things about your competitors on a fixed regular schedule. As a result, I have yet to meet a daily (weekly, etc.) standup that hasn't devolved into "I worked on this, I will work on that." to escape the awkward silence.

No one wanted to tell them that it isn't cool, we are all burned the fuck out, the work load and pace are rediculous and most of us can't wait to fucking leave (I'm on the way out). They worshipped us, kissed our ass, were genuinely sincere, but they just don't get it. Oh well, the managers will get promoted, again.

Alternatively, it may be the case that your leadership team is relying on the Process to insulate them from their responsibility to promote the well being of their employees, and from the loss that naturally follows when an important member of a vital team leaves the company. Rather than viewing their team as a resource to be nurtured and developed, they view you as a liability. Such companies instead develop their Process to such an extent that any member's agency and responsibility is effectively zero. Team members act like hamsters in a wheel, spinning endlessly, consuming an infinite treadmill of tickets and producing result units in 3x to 10x the amount of time it would take an empowered, impassioned developer. These inefficiencies are viewed as acceptable, even inevitable-- so deeply do they fear their employees taking meaningful ownership of their work.

Many such cases.

[Citation needed]. I find standups and their context switching cost me at least an hour of productivity each day.

> Team communication has no value

If you want to communicate with your teammates, just use Slack and communicate instantly, why wait for the next morning's standup? If anything, standup slows down communication.

> Team leader having a chance to quickly gauge progress

You mean like the [insert ticketing system] board? Why do we have to waste time talking about stuff that's already being tracked?

This doesn't fully excuse it, but the more closely management is watching team-work-coordination tools like ticketing systems, and the higher the level of management that's looking at them, the more prone they are to drift from reflecting reality. That a standup is, by default, not transparent and recorded for anyone else to look at, is, in some organizations, and if they're run properly, most of their value. Granted, yes, that's a work around for a broader cultural problem and shouldn't be necessary, but the real world's a mess.

This can be badly managed, as is the case in your examples. You're right that there shouldn't be more than 8 people and it definitely shouldn't take 45 min. 15 min max and if there's more to quickly discuss the people involved should stop and continue after the meeting. The situation you're talking about with crisis mode sounds like planning rather than standup and if you're Engineering Manager is declaring crisis mode and hijacking standup each day to spend an hour planning then you've got major cultural/organisation problems. In that case standups are just a symptom not the root cause.

There's also the social aspect, which other comments have mentioned. I've always found that underrated, though I was recently reading about how some national cultures rate it a lot more than others. For me as a Brit I always feel far more comfortable communicating my colleagues when we get on socially and we understand each others sense of humor and communication styles. Taking that time to banter for a few min each morning is massively important for improving team communication. And during lockdown and WFH it's been even more essential.

That can easily happen. On the other hand, where would you expect an EM to ask individual questions that matter to them ?

My experience as an EM is that this really depends on the team, including domain and maturity. For example, if you have a team of mostly junior members, well, the "micro managing" version of standup is often useful. It gives a way to see how people can communicate their issues to other team members, especially when you're new as an EM.

For more mature teams who don't have issues, I generally don't do standups, unless there is something critical and the project priorities at risk.

In the one place I was in that did Scrum, the org had rules:

1. The "Scrum Master" is external to the team.

2. If the manager behaved this way, the Scrum Master would kick him/her out of the room - permanently if need be.

Worked well, and realistically, managers don't really want to be there.

Addressing standups as the sole issue completely ignores the holistic factors that influence the outcome. If a team is bored, undercompensated, overworked, undersupervised, then they're going to deliver shitty standups, and those standups will be a waste of time. When the participants are eager to provide a handoff of knowledge and prompt eachother for interchange, then you get the good standups that leave people racing back to their desks to build off of that synergy.

What are you supposed to say then?

Daily is way too ofent to have anything interesting to say. It is a low effort way for the manager to keep track on things and make people feel stupid for not doing progress in the maner the agile scoreboard dictates.

Daily stand-ups are for coordinating with the other devs. E.g. "It will take a couple extra days to do this backend API that you are waiting for", "I'm a bit stuck, anybody will have free time today to pair program?", "Who is able to drop their low priority task so that the high priority one gets done on time?"

If you're on track and don't neet anything, just "no updates today".

The first 25 years of my career as a programmer we never had daily stand-ups, had never heard of them. We shipped.

Something about all the "process" that has crept into the job over the last decade or so has really turned me off.

Seriously, it was only "main" when I started at Apple 26 years ago. Our version control was such that when someone wanted to edit a file it was "checked out", locked to others on the team, until it was checked back in.

It worked surprisingly well (obviously no merge conflicts for one thing). I doubt anyone would suggest going back to something as simplistic (but I have to admit Git feels way too complicated than it should at times).

There's a huge difference between a "daily progress meeting" and "sensible development". I too have seen a lot of process creeping into things and I'm glad I'm getting close to retirement.

"

Why do you need standups for this? They should talk to each other directly.

I have been to a team where X would need help on something that Y has solved in the past, Y does not care to listen in the standup and volunteer to help, and i had to ping him “Hey Y you have resolved this in the past, care to help X after the standup?”

Shitty standups go bidirectional ways. Managers can make them terrible, but devs can do that as well.

Which work orders? Which PRs? How much progress? Are they harder than expected? Easier? Any blockers? Anything that could help?

Standup isn’t just for managers. It’s for ICs to also communicate their needs, obstacles, concerns, or even just give everyone a heads up that a certain task is more difficult than expected. If you’re just searching for the bare minimum to say to get your manager to move on to the next person, it’s a waste. It’s only a few minutes, so take advantage of it for some quick bidirectional communication.

  Tackle: I'm going to block. No blockers (err).
  Tackle: I'm going to block. No blockers (err).
  Guard: I'm going to block. No blockers (err).
  Guard: I'm going to block. No blockers (err).
  Center: I'm going to snap the ball then block. No blockers (err).
  Running back: I'm going to run. No blockers.
  Wide Receiver: I'm going to run then maybe catch the ball. No blockers.
  Wide Receiver: I'm going to run then maybe catch the ball. No blockers.
  Wide Receiver: I'm going to run then maybe catch the ball. No blockers.
  Quarterback: I'm got to receive the snap, then do something with the ball. No blockers.
  Tight End: I'm going to block. My blocker is that my shoe is untied.
  Guard: You should tie your shoe.
  Guard: You should tie your shoe.
  Running back: You should tie your shoe.
  Quarterback: Would you guys STFU, we've got stuff to do.
  Tackle: Daily standups are important for morale and communication.
  Referee: Delay of game, 5 yard penalty, repeat the down.

In other words, if you have plenty to talk about in your stand-ups then you are doing something wrong. Which is the point of Scrum, this fixes communication issues, but your team really shouldn't need this.

Yes. The other difference is that football has absolutely nothing to do with software development whatsoever, so why organise as a football team, that just seems like a bad joke to me.

If only this we're always true. In reality your teammates can be busy which means queries to them will often go unanswered. Standup is the only time to guarantee responses from busy people on the team.

So it's basically impossible.

Whenever someone says "This [meeting | standup] could have been an E-mail!" I respond "So do you read and respond to your E-mail?" I love asynchronous, but the entire team has to put in the effort to make it work.

If the only time ICs communicate any of that stuff is at a set time each morning, then something is already seriously wrong.

Agreed, It's much more productive to simply approach some of your coworkers, or write in a team chat after the daily. Mentioning problems in the daily just adds pressure and stress with no benefit.

The ones we already discussed were in progress. Did you expect it to magically change overnight?

> How much progress?

Paterio already went over this with you. I am 80% done. Tomorrow I will be 80% though the remaining 20%. The next day I will be 80% done with the outstanding 20%.

> Are they harder than expected?

Yes. It would be far easier if you didn't interrupt me.

> Any blockers?

If there were, and I haven't already told you, why would I tell you now?

> Anything that could help?

Not bothering me until I am at a stopping point.

--

What's the purpose of the standup again?

We are talking about daily standups. In all likelyhood, you don't encounter blocker that often. If you have frequent blockers, then you have larger issue. In most days, I don't need help at daily standup time. If I needed help, I asked before and did not waited for standup.

> Are they harder than expected? Easier?

What would that be useful for? Like, I do quick venting sometimes, everybody does, but I am not under illusion it is useful for others.

Sometimes things progress without any surprises or blockers. A meeting just for the sake of having a meeting seems like a waste of time and effort.

A plain old developer, who does not manage other developers.

On the other end, having to report things based on a timeframe that tight relative to the work done will quickly devolve towards finding things to report on, no matter how unnoteworthy. Teach people to speak up and show noteworthy things instead and have a bit of faith in your other metrics and report pipelines.

Nobody does this, they do it immediately, at least all the places I've worked. I need help, first I try to figure it out myself, then when I'm stuck or want to make sure I'm doing it right, I ask the owner of the code I'm working with. This makes standups not only redundant (information has already been shared) but distracting.

>But, I do see the point of a daily sync up for team building, especially for remote teams.

I've found it to be a morale killer more so than a morale booster. Fuck I gotta stop what I'm doing for this stupid standup, or I'm not gonna do anything because the standup is in 45 minutes; I'll just get distracted.

I was once at a place where you actually stood up and the standups were 45 friggin minutes long. Total waste of time and I was so demoralized after it took me 30 minutes just to decompress and get stuff done.

They would be slightly better if done on M-F-W or even more so on T-TH. Once a week meetings for about 30 minutes with biz then 30 minutes with dev works great for our team.

(d) creates a daily source of anxiety for developers who doesn't handle public speaking well. Which is a lot of them, but it is a shameful thing to admit.

Instead I see someone who questions the utility of this particular daily ritual. If others on the team feel the same way then it's more like they're calling the emperor naked.

Also see you working on one large project or a bunch of small projects ?

There are no bad teams; only bad leaders. -Jocko

Took me a long time to buy in to this but it's 100% true. Sucky standups are the direct result of an ineffective leader - whoever that may be.

And it makes sense- even if the team is "objectively bad", a good leader will help transform them.

They will only do them if they're dictated by the company, or the the team members are unable to work and communicate independently and requiring constant micromanagement. The latter is usually a case when the team members are provided by the outsourcing company, or they're some kind of "team extension".

In that environment, the individually rational strategy is not to reveal much, look busy, don't stick out much etc.

So, people end up listening to the newly minted scrum "master" pontificate on value or the grooming habits of their pet.

In a healthy environment, standups are developer-to-developer conversations. Dev A says "I am having a problem solving X" or Dev B says "I found out that 3rd party service API we are relying on was suddenly phased out, we need to rethink the entire approach", and people can figure out a quick response. Sometimes the solution is pairing, sometimes it's a change in other plans.

Public information (who is working on which ticket, which PRs are open etc) do not need to be repeated. Standup is not a place to list accomplishments: Of course, if a particularly thorny problem has been solved, that calls for celebration, but 30 seconds is more than enough if nothing unexpected happened since the last time.

I do prefer in person synchronous standups so that an impromptu discussion of how to handle anything unexpected can happen with everyone's input.

Yes, that's the reason. If you know the work you do doesn't matter, you're going to get subpar results.

I won't speak for everyone, but the work I do doesn't matter. I do the work to get paid. The alternative is not get paid. I don't really have a choice. Something that I would consider matters more: building something with my hands like construction, electrician, trades, grocery workers, social services, train workers, factory workers, agricultural workers, bus drivers, etc. That stuff matters in my mind more than whatever widget I'm being paid to make. Those jobs are what keep society moving.

I suspect that for most people in tech, most of the work people do isn't benefiting society and the masses in a good way, it's just a way to make more money for other people. So, it's natural to not believe that their work matters. You have to convince yourself that it matters.

With that said, the solution is a restructure of society that encourages and reinforces work that people find meaningful. No little scrum standups will change any of that. If you truly believe that what you do is meaningful, then you'll get better results. Along those lines, you often hear the question, "What would you do if you didn't need a paycheck?"

The alternative is to switch to paid work that does matter (to you). If you lack the skills to do work you find meaningful, then learning those skills is the next step.

Your comment seems pretty thoughtful overall so I'm wondering if I'm misinterpreting the world view you tried articulating at the beginning.

Upvoted, but, I've seen non-shitty standups where the effort people put into to make stuff work was valued both by team mates and management and that did not involve venturing into Marxian territory.

Agreed, but those people must truly believe that their work matters.

I'd extend this to the very existence of rigid roles such as 'project manager', 'qa', etc.

We've traded the existence of healthy teams and healthy individuals in exchange for predictable insert/delete commands of any team member by the management caste.

That this destroys morale and human's natural desire to connect and form lasting bonds doesn't seem to bother the management caste. I guess why would it, it's modelled after master/slave or aristocrat/pleb relationship of the past.

I don't go that far. Project management, qa, ops, and programming are largely disjoint skillsets.

Your blocker can be used by another opportunist to talk garbage solution. It makes the opportunist appear as if they are doing something that the blocked engineer isn't doing.

The blocked engineer could counter - but it will quickly devolve unless one side concedes.

Standups are only a tool for micromanagement - nothing more.

One of the biggest reasons to time-cap it is that overall...it really isn't a good use of time.

On the other hand people are far too over the top acting as if it's the most awful thing they've ever had to deal with (it's 15 minutes and in most cases the only meeting you're going to have that day). People who can't tolerate a 15 minute chat with their team tend to have a lot of issue working well with others in my experience. The "I can't spare 15 minutes" mindset tends to live with people firmly in the "all about me" world.

It can be hard to get out of the bubble of the work that you are doing.

EDIT: I totally get bad scheduling that interrupts flow time. IMO either beginning of the day, end of the day or just before lunch is the ideal time to do it for that reason. Time zones also complicate it.

People need to emphasize that the problem is the bad scheduling of the time slot rather than the 15 minutes itself. Also, it's a good idea to make skipping it periodically totally acceptable.

A previous team I was on had standups at 10 am. This meant even if you wanted to start working earlier and get heads down on something, there wasn’t much point. Add in the typical context loading time and that meant you weren’t really able to get going until 10:30. And guess what? At that point, lunch is an hour and a half away.

Most of the time there's no managers and it goes like that:

  - What you work on yesterday?
  -- I've worked on automated tests X, Y and Z, had a few meeting with an analyst to validate the tests.  

  - Did you had any issues.
  -- No / I had a few issues about the X process, is there anyone that could me, I have a few questions ? 
  
  - What are you doing today. 
  -- Today I'm going to work on X Y Z with XX and I have a few personnal meetings about X Y Z with Team X for Project Z. 

I am not denying genetic traits, but like with most things, it's not the only factor.

10AM already is before my definition of "first thing in the morning".

Maybe we should just kill the synchronous status update meeting altogether and avoid conflicts like these?

It's awful when it's interrupting valuable flow time.

> in most cases the only meeting you're going to have that day

If only that were true!

In other words - micromanagement.

Except the requirements for transparency is only for the developers, which makes it feel very degrading, all of the other people in this meeting, the leads, scrum master, product owner, ux etc, don't say anything about what they're doing, and they have no board with their tasks either so no transparency whatsoever.

It's supposed to be like a restaurant where all the waiters share tips. It is in everyone's interest that one, all customers are being served well and two, that all waiters are pulling their weight.

Why would I wait for some meeting the next morning?

You wouldn't. Why are you under the impression that scrum prohibits communication outside standup?

Daily scrum is a floor on communication, not a ceiling. It guarantees that focused communication happens at least once a day. Sometimes people miss slack posts and emails. Scrum makes sure the entire team is aware of progress and blockers. It's a tiny slice of the day when it's done properly.

No. There may be occasional cases where that's true, but it's almost always better to get another pair of eyes (and accompanying different experience) on a problem. There is some great software that comes from solo devs, but most commercial projects are simply too big for one person to accomplish in the time necessary. Business software is very much a team sport.

How long do you think your manager should go without knowing what you're doing?

I once suggested that instead of standups developers write an end-of-day comment into whatever ticket they're working on. This would enable managers, others, by filling the blanks that status change/VCS timestamps might not tell you. People just looked at me like I was crazy when this would be even more efficient.

Don't like the Burndown Chart over the course of a year? You can literally look at the Sprint Reports to see what issues/assignees are spilling over a course of time. Managers have all the tools they need but that's not the point of this stuff. The point of this stuff is to reinforce that they are the boss. They could even make the SCRUM Master's job actually useful and be responsible for this kind of research but I've yet to see a SCRUM Master be anything but a proxy for this antiquated posturing.

Just as much as there's a general fear that labor is hiding behind process, so is management.

A weekly status update is good enough for regular status. I must mention that if you are looking at status reports from the time dimension, you have already failed.

The manager should cultivate an environment where engineers and managers talk in small groups at any time. There is no need for a standup for this. Everyone can decide for themselves if they need to spend time with someone else. The manager can decide for themselves if they need to chat with a report instead of taking away time from all reports everyday.

Of course, this would require the manager to do the work to chat with reports and figure out what's going on.

That is not the team composition most people are working with. The median developer in the industry only has a few years of experience.

Most of my teams problems with Agile/SCRUM come down to skipping steps or not following best practices. Once we fix those, it gets better.

If you read the agile manifesto, there are no specifically prescribed steps or rituals, and in my experience, most teams implementation of scrum is entirely counterproductive to actually being agile. The core tenet of being agile is essentially people over process, and things like daily stand-ups, extremely formulaic retrospectives and backlog grooming meetings do nothing to empower the people and allow them to be truly agile.