I think spending 15 minutes is great.

But in 15 years, any time a standup was below that target, people commented on how unusual it was to be done already.

The standup is either early enough in the morning that it becomes a passive aggressive way to get people to show up 15 minutes early to work (because if you try to show up on time, you'll be late for a short meeting, essentially missing it), or it is late enough that early risers have to avoid flow state tasks early in the morning or also miss the meeting.

If you are in the middle of something, a 15 minute meeting clears working memory every bit as much as a 3 hour meeting. So if you're going to lose your spot, you might as well get something else out of it. Which contributes to the "but it's never 15 minutes" phenomenon.

I just got out of my team's standup. MY team has 8 people. The standup lasted 6 minutes. I think the people who complain about this, are the ones who have a reason to complain. You don't hear the success stories.

> I just got out of my team's standup. MY team has 8 people. The standup lasted 6 minutes. I think the people who complain about this, are the ones who have a reason to complain. You don't hear the success stories.

I'm not sure if I'd count a 6 minute standup as a success story. My guess is the only person deriving any value from it is some kind of manager who's tracking status, and pulling everyone into a meeting room to do that is mainly just a convenience for that person.

The kind of information that can be conveyed in less than 1 minute per person is likely information that can be collected less disruptively in other ways.

From my perspective as a developer, the best "standups" were the ones that actually deviated from orthodoxy, where we talked about some technical issue or something.

There are many templates for failure, and the funny part is that often the people who contribute to the failure are the ones complaining. But in all cases a good scrum master should be picking up on this and fixing it.

Most typical one is that a team member wants to go deep into details about a task which isn't important and not the case. And after explaining for 10 mins about how they where brilliant in so many ways, they complain when the rest of the team "wastes" their time spending 5 min in total explaining why that brilliant feature was actually not needed which is why it wasn't on the board and no-one asked for it etc. The solution here is to repeat time and time again what the purpose of the meeting is, and cutting people off mid explanation when they go outside their timebox Note though, don't do individual timeboxes unless you are facing this specific issue, it's not good overall but sometimes you need to correct behavior.

Then there are cases where team members aren't paying attention to others and complain the stand-up is wasteful because they never learn anything new anyways, but when you talk to other team members that person spends the rest of they day asking questions that where already answered at the daily. Obvious here you need to do some coaching for that specific member, but I've found it also helps to let them not do their own points, either skip them completely or do them for them. My experience is that it's often coupled to that person going through what they need to say and forgetting to listen.

And on and on. There are so many cases where teams need to correct bad habits rather than complain about the stand-up being there. But sadly the retrospective is often the first thing to go out the window on teams, and they never get to discussing overall how the process is going, and then the daily stand-up gets changed into a 30 min status meeting, and people start hating it.

LPT: schedule your standup for the 15 min before lunch. It’s an almost automatic way to ensure that it finishes quickly. No one wants to be the one that’s making teammates hangry. It also means the meeting never interrupts a developer’s flow since they were going to break for lunch anyways.

This also means your team's day does't start until lunch.

Why do you think the daily stand-up should be the days starting point? That's not a requirement and not at all practical. If you have to skip a stand-up some day because of a dentist appointment or other meeting, do you just not do anything for the rest of the day?

Um, no. My day starts at 7:30 or 8:00 am. Standup is at 11am. I'm about 1/2 done with the day when standup happens. Other folks on my team start work at 10:00 am, so it's closer to the start of the day. I prefer having 1/2 day to get stuff done by the time standup rolls around.

Have you forgotten to have retrospectives? Yes, the first 2 weeks, the stand-ups is badly place, then the team talks about it and chose a different time. (Remember the team decides the time, not management or Product owner), management only gets to decide that you are doing scrum, which means you need to have the daily stand-up.

If you've goon 15 years without any stand-up being under 15 min, then you are doing something wrong. Is your team absurdly large? Is your scrum-master not fluent in scrum? Does no-one in your company understand how a time-box works? Or do you insist on bringing up lengthy technical discussions that you could perfectly well take with the 1-2 people involved outside of the stand-up? There are tons of ways to do it wrong, and pretty much every single one comes back to people not understanding what the stand-up is and isn't for.

It's popular to shit on scrum, but a lot of the criticism comes out like someone going "Programming in C is rubbish, it always throws segfaults, and it's impossible to create good software in a programming language that isn't pure functional" It's an opinion sure, but it's based off of being bad at coding C and preferring to code in Haskell, where you might ask the person if they had considered actually learning C before shitting on it.

> If you are in the middle of something, a 15 minute meeting clears working memory every bit as much as a 3 hour meeting.

Getting interrupted for a 5 min talk with a colleague is just as interrupting to your flow. Don't pretend to claim that everyday in your 15 years of scrum you have accomplished absolutely nothing on a day if there was both a daily standup, lunch, and a person asked you question.

Yes interruptions are bad and should be minimized.. which is why having 15 min condensed to get everyone aligned is better than having 5 people dropping by randomly to ask "did you commit the feature yet?" "Was it me or you who was supposed to do X" "You do know that I'm waiting for you to finish Y right?" "Are you waiting on me to do Z, cause I prefer doing X first, but no-one needs that yet". And again, if a team has more than 15 min total of those kinds of interactions during a day, you need to reflect and improve. If you have less than 15min, then great, everything is cleared up after the daily scrum.

Agile retrospectives are supposed to include discussion about switching up your process to deal with a problem.

Lean management is about picking a small number of processes that are easy to remember and keep backlogs ('inventory') from becoming a liability. And then sticking with them.

I've heard it argued by a former mentor, and people who write books, that Scrum is/has become a Lean process. I still haven't found a counterargument that I think will convince any of them.

A process that is meant to engage everyone in fixing everything but the sacred cow draws attention to the sacred cow. The dissonance is something that people who spend all day thinking in terms of logic prefer not to look at, and so this makes some people angry, others sad, and everyone uncomfortable.

> Have you forgotten to have retrospectives? Yes, the first 2 weeks, the stand-ups is badly place, then the team talks about it and chose a different time. (Remember the team decides the time, not management or Product owner), management only gets to decide that you are doing scrum, which means you need to have the daily stand-up.

Sure, that's the orthodoxy, and assumes the team is actually empowered to do that, but agile-as-practiced often doesn't actually address the problems that it was supposed to solve. In many ways it just replaced one set of ceremonies with another, leaving the fundamentals unchanged.

It's interesting--I completely and utterly agree with out intellectually. But when I look back on many teams I've been on in many companies, daily standups achieve this sort of psychological weight of monotony. Even when they're below 15 minutes they take on a dread.

I don't think this is exclusive to standups: any type of process done repetitively over time can get this upward curve of increasing monotony, even if it doesn't lose its inherent usefulness.

The very act of changing or intervening in a monotonous process might be a boost for people, and to your point is not an argument against the usefulness of the process. I've equally had teams not doing standups get a boost from starting to do standups.

Coming from doing a lot of recommendation systems work, it's similar to how just changing algorithms around often leads to a temporary boost in engagement which then regresses back to the mean (same in general A/B testing).

When I'm managing a process and someone comes to me with a process change suggestion, and I feel like I am well-stocked with evidence as to why the existing process makes sense and is efficient, I now have a meta-assessment where I consider the change because it will at the very least mix things up and introduce changes to thinking. Obviously that is not to be done willy nilly, but my younger self would have pushed back on process changes that were not inherently superior to the existing ones.

There's an in-between here. Daily standups just aren't a great fit in many cases... weekly standups will tend to work better in these cases. At the end of the day it boils down to the difficulty of the tasks to be executed and how much R&D and design work there is. The more R&D heavy your workload the more impractical daily standups tend to be.

Yea, we did stand-ups Mon, Wed, Fri, which tended to be a good balance. Still able to let people know what you are doing, but not having to be forced to do it everyday as if you are children.

> It’s not wasted time, and even if you don’t care what I’m working on I still care that you know so that we don’t spend two weeks building something only for you to go “Oh, that won’t work after the changes I made to the core.... why didn’t you come by my desk and ask me “are you intending to change the core code in a way that invalidates all assumptions we had two weeks ago when we started working on this?” And do so like clockwork every day, even though I’d answer no 6 times before suddenly answering yes?

I thought the whole point of orthodox standups (and one of the brain-dead things about them), was that you weren't supposed to have discussions at that level of detail.

You are absolutely correct and people not knowing this results in a "standup" that balloons into a one-hour verbal trash bin. This is the issue my company has. Daily "standups" that can take 30-60 minutes.

BUT WAIT HOLD ON, it's 15 minutes of "standup" and 45 minutes of "parking lot." eye-roll

This is every single day, by the way. Our previous manager got the picture and reduced these to three times a week with hard time limits. Then a new manager came on and put daily "standups" back on, after apologizing that he was adding a meeting to our no-meeting day, lol.

I'm dead inside.

It also psychologically feels bad when you have the same update every day (e.g. working on a long-term project) or if you have no update. It's also really fucking stupid to have a "standup" on Friday morning and another on Monday morning.

I'm dead inside. I'm dead inside. I'm dead inside.

Also I take any opportunity to vent about these stupid "agile" methods, sorry.

I know this isn't your place to fix, but honestly align with your scrum master and just stage a walk-out of the "parking-lot" meeting for you and the team. You should not be required to attend this.

After doing this a couple of times people will realize that there is something wrong if you have to spend 45 minutes a day digging deeper into issues. Poorly planned spring backlog? A non-existing product backlog? There could be many issues, but trying to "patch" them by doing things wrong.

> Also I take any opportunity to vent about these stupid "agile" methods, sorry.

So I'm sure you've raised these concerns at the end of every iteration at the retrospective right? Please tell me that you didn't throw out the retrospective and the process for venting frustrations to facilitate change and then start changing the process completely and then end up being bad at this thing you are doing which definitely wouldn't be scrum then.

Currently, a lot of the members on our team just miss standup entirely. For example, I missed the last 3 days of standup. Showed up today to re-iterate that I'm making some prod changes. Our sprint backlog and sprint planning meetings are a disaster, too. Watching our manager struggle every single time with jira is just.... mind-numbing. We complained about those and did get some changes made. For example, our sprint planning "meeting" went from two 1.5 hr meetings (one before lunch, one after) to one 1.5 hr meeting before lunch. I sometimes miss those, too.

I raised these concerns with this manager when they first started (specifically about the number of meetings AND the daily standup). I raise them in the retrospective every time we have one. I raised them with my engineering team manager. I raised them in those anonymous feedback things.

We're currently in the process of getting this manager out of our team. Our manager went on vacation and our productivity went up by some crazy amount, lol. The only thing keeping us stuck at this point is the current covid situation (long story). But normally, I'm pretty sure they would have been gone as of a month ago or so.

It's an organizational thing, though, not just that manager specifically. Half the battle is getting upper management to listen to our concerns and do something about it.

But the reason our last manager was so good about these things is because he had clout within the company and the assertiveness to say "no, that isn't ok."

Yeah, standups are for triage. If someone raises an issue then you work out who they need to talk to about that and arrange for that to happen. The details get hashed out in the separate smaller meetings (or 1:1 conversations).

> Yeah, standups are for triage. If someone raises an issue then you work out who they need to talk to about that and arrange for that to happen. The details get hashed out in the separate smaller meetings (or 1:1 conversations).

Honestly, I expect competent developers to be able to do that on their own, without needing someone to make arrangements or having to wait for a standup.

It can be convenient to have a set time each day. Because it means non-urgent issues can be taken care of without disrupting people while they're in the middle of something.

I think the disparity is that, for most organizations, Standup isn't "talking to your team to ensure that you know what others are working and and they know what you are working on", but instead "A person gives vague generalizations about a story/ticket number, the rest of the team pretends to listen."

And yes, sure, that is objectively not the point of the meeting and blaming the meeting for people misbehaving isn't right. But it's a cowpath argument to me. If the meeting is in service of a team and their collaboration, collaborate in the ways the team finds most meaningful. Do not force a team to pretend to be collaborating.

Except that a stand up doesn’t actually solve the problem you are referring to. People don’t pay much attention to what you’re working on in stand ups since it’s most probably not relevant to what they’re working on at the time. It is unreasonable to expect people to have perfect foresight that what you’re working on is going to be relevant to them 2 weeks down the line. There are better ways to solve that problem but stand ups is not one of them.

> It is unreasonable to expect people to have perfect foresight that what you’re working on is going to be relevant to them 2 weeks down the line.

I would understand if you said 2 years or 2 months. But if your road-maps and plans change so rapidly that you can't even assume that features coordinated one day will still be relevant 2 weeks after... then how on earth do you have a functioning team without daily communication? And if you do have daily communication, why not concentrate that to a single max 15 min period to reduce being interrupted in flow?

The nature of changes is that you cannot predict them in advance.

Even if you knew your roadmap for 2 months and were operating perfectly, something unpredictable could happen, as things do. Such things don’t give you any kind of notice before they happen.

In such an event, you can’t be expected to remember something someone told you 2 weeks ago in passing anyway. Standups are a short but heavy information dump and are not good at facilitating recall as time goes on. This is true especially if you are operating in a rapidly changing environment such as a startup.

In another system, like XP, the standup might allow you to absorb a lot more info about your peers. Within the metronome of Scrum, too many people are under time pressure to save face and are likely to say their but and tune half of what everyone else says out entirely.

I completely disagree. As a developer, standups have always ended up devolving into the bane of my existence, and now I only work for companies that don't do them (or at a minimum, allow them to be async).

Not all of us enjoy being micromanaged.

Standups aren't the place to hash this out, sprint/epic planning is.

Standups are for managers and 99% of the time can be done asynchronously. If you have to know what everyone else is doing in order to be effective at your job, your planning process needs fixing.

How would the standups be for managers? They don't attend. Even the scrum master is not required to attend, only required to ensure the meeting happens (which for most teams often means the scrum master has to attend, but still.)

I've never had a standup my manager wasn't at. I know they're not supposed to but like, theory vs. practice etc.

Standups are also for people who like the illusion of control that comes with knowing what everyone is working on and having a say in every single decision/work.

Standups (weekly, not daily) worked pretty well for us at 5-20 people: maybe 5-12 devs and 2-8 other stakeholders. Smaller than that, and communication was so easy and natural we didn't need standups. Bigger, and it became tedious and low signal (everyone didn't need to know everything).

We now have more than 50 devs, and we've remained quite flat and autonomous. It would be literally impossible for me to track what all the other devs are working on, never mind going over it every day in 15 minutes. It probably works better for siloed dev/product teams that stay under 30 people, but that's not how we work.

I share all this to give perspective on a pretty bold statement: "If you [don't like standups], then I don't want to work with you." Ten people is a good size for standups, and I think you may be overgeneralizing your experience when judging people who don't like standups.

Even still, I'm curious how much is changing daily to warrant daily standups? We have a rotating "release team" who runs QA and ultimately performs releases, and they check in daily. But daily checkins for feature development seem very frequent to me.

Our team doesn't do daily standups as everyone pretty much knows what other people are working on. There's communication on Slack. There's a list of issues and/or roadmap items that are assigned.

Then again, we have a small and high functioning team where there's no "waiting for X to finish Y" or blockers that aren't resolved immediately via communication on Slack. There's never a lack of issues to work on. Nothing assigned to you? Well, pick something from the list of issues or something on the roadmap, communicate to the team that you're working on it, communicate when you're done.

For a team of 6, 15 minutes a day is 90 minutes of productivity. That's 7.5 hours a week, pretty much almost a whole day of productivity for a person.

Whether standups are great for your team or not depends on the makeup of your team and personnel, the size of your team as well as the nature of the work and how work is divvy-ed up. I've found success on teams with and without standups, and I'll say that not having 15 minutes of the start of your day spent on being in a meeting is absolutely refreshing

In my opinion standups are waste of time when they are mandated by some boss. When they are used as head count moment to see everyone is in the office working on things. Then it turns into status report for that manager and maybe he starts even micro managing people by handing them tasks and asking questions to each person.

If standup is needed by the team and it feels natural then it probably is useful. Nowadays with remote work I kind of like to have at least 10 mins to see people that I am working with each day.

Imagine having to speak and say what you are doing in about 2 minutes. The horror. Part of your job is communicating what you are doing to others. It is common courtesy and a social skill. Cultivate it.

Stand Ups by nature are to be quick. It is why YOU DON"T SIT.

You can do them over Teams, Zoom, Slack.

Companies allocate millions to billions of dollars for projects and have a need to know how things are progressing and if there are issues and resources that can be brought to bear to solve them.

If your manager or "Boss" is micro-managing you to death, then leave. The culture is toxic and a 10 minute stand up is the least of your issues.

That's not communicating, a daily standup IS micro-managing. It's an incredibly destructive and soul-crushing anti-management technique.

No-one needs to have daily updates. Weekly, twice weekly, maybe, daily is simply treating people like small children.

Communication is a two-way street, not irrational cargo culted standups.

Found the bug in your process in line 1. Managers shouldn't be attending your daily stand-up.

I find the whole standup discussions hilarious. Primarily because the same discussion will always have massive proponents of stand ups offering at least 2 completely contradictory justifications for stand ups.

1) Standups are for knowing what your team is up to. 2) Standups are for removing blockers.

If (1) is correct, then let’s just call them what we always did before the SW Project Management Industry decided to buzzword it. Status updates.

And if they are status update meetings, then the simple question becomes why they should be daily. Their cadence should be dependent on the type of work the team is doing. If the type of work you’re doing means the majority of your work items are done in a day or less, then by all means have a daily status update meeting. However, if like many teams, the majority of your work are items which take 2-3 days, if not weeks, to complete, then why not just do 1-2 status update meetings a week?

And when it comes to removing blockers, why have a daily meeting at all. Why not do it in an async format using mailing lists (or Instant message/Teams/Slack/etc) instead. That ensures you’re not blocked waiting for the standup, and everyone is aware of your blocker as soon as is convenient for them.

In practice, however, Standups tend to be a mixture of both (and that’s how they are usually defined...what you did yesterday/what you will work on today is status updates, and blockers is about removing impediments). And that makes even less sense from a purely theoretical perspective (never mind the scores of practical experiences where it’s been a disaster), because those 2 tasks have different ideal cadences. Blockers are something that should be shared immediately, as they happen. Status updates, however, should have a far slower cadence, where you need to balance the need to keep the team informed about your work, and share progress towards goals, with the fact that each update is an interruption, and so the ideal cadence would be dependent on the nature of the work the team does.

The idea of a daily standup is a good fit only for teams whose work happens to be such that once a day happens to be an appropriate cadence for their status updates. And even then it’s not a good solution for the blockers removing aspect.

We occasionally spend 20 min on Tuesday and Thursday, at around 14:00. That's enough for us. But then again, we're in a very unusual position as a team.

You're conflating not knowing (or caring) what's going on with a meeting. You absolutely should care what's going on with a team, because if you're work isn't affecting each other there's little reason for you to be a team. That communication shouldn't be every day though, it should be constantly available to whoever needs it at the time they need it.

Software can achieve this, and it's what my startup is trying to make happen. The key is to unify status-as-in-state with status-as-in-active-communication so the two can inform each other.

This suggests a fun exercise:

Once a week, maybe right after each person says what they did, everyone gets randomly assigned a person and they have to explain what that person did last week.

The goal of this exercise: Make people actually pay attention to what others are doing and ensure they really understand it (and feel empowered to ask questions if they don't)