
The pointlessness of daily standups - mttyng
https://codethrasher.com/post/2019-10-06-the-pointlessness-of-daily-standups/
======
vfc1
I've worked in many teams that used standups, the general feeling was that
they were utterly useless.

Except for management, as standups are a simple way of keeping psychological
pressure on developers and squeezing every last bit out of them.

I even saw once a developer on his last day throwing the speaker's token (a
teddy bear) to the trash can LOL!

Everyone on the teams I worked on seemed to think that standups where useless,
this showed clearly through the team body language and tone in those meetings.

Its an interruption on your work just when you just got started in the
morning, now you have to stop and go to a meeting.

What people are working on is usually unrelated and of no interest to each
other, and if you need help you ask it anyway on the spot, there is no need to
wait for the next standup for that.

It's hard to come up with different things to say on the meetings, as there
aren't many things that have changed since yesterday.

~~~
cmrdporcupine
Back when I first started doing daily standups at jobs almost 20 years ago --
when agile/xp was first starting to buzz -- it honestly felt like a breath of
fresh air and explicitly something that management would _not_ want. Quick,
informal, brief checkpoint with your coworkers, then back to work. We had a
group of almost 20 engineers & QA people in a circle, but it went quickly and
inobtrusively... nobody spoke for more than a few seconds. We all knew what
everyone else was doing, and could go offline and have a discussion afterwards
if necessary.

It was a meeting for ourselves, not for management. There were no status
reports to management, no gantt charts, no percentage estimates of completion,
etc. Just: here's what I'm doing/not doing.

Fast forward a decade or two and I've seen good and bad use of this meeting
form. But I still think it's a good idea, it just requires discipline to stop
people from hogging air space or veering off into tangents.

~~~
ubermonkey
"It was a meeting for ourselves, not for management. There were no status
reports to management, no gantt charts, no percentage estimates of completion,
etc. Just: here's what I'm doing/not doing."

That's my understanding of what a standup is supposed to be, and it's what my
experience of them has been. THIS is useful. It's in particular useful if you
have devs on the team who tend to get kinda "wound around the axle" on
problems rather than speak up or seek help.

There will always be devs who think any meeting is by definition a waste of
time, and you can't make those people happy, but a true brief standup meeting
as described here is SUPER useful.

(Daily's probably too much though.)

~~~
ownagefool
Like many things, if it works for you and doesn't turn negative, then that's
great and more power too you.

Personally, when I lead a team, I keep abreast of what people are working on
and ask them if they need help, or tell one of the more suited senior guys to
offer a hand if it's an area I can't easily help in.

I imagine the standup helps more when you're lead is a non-technical scrum
master guy who doesn't have much of a personal relationship with the team.

On the latter point I typically buy my team members fancy coffees and the
occasional lunch, and it's easy to get on with them if you care about their
careers, so I've never needed a standup.

~~~
cmrdporcupine
That's the point: the stand up is for the team, not the manager. She/he should
stay out of it.

~~~
ownagefool
That's a difficult argument? Is the manager not part of the team? Depends on
the org, I guess.

Either way, I'm not so sure the statement means much. The point of agile is to
do what's helps, so if a standup is useful for the above reasons, it's entirly
possible that another approach solves the same problem, negating the need for
the standup.

~~~
cmrdporcupine
It definitely depends on the structure of the org. But I do make a distinction
between management and team lead. On some teams the management is technical
and involved in daily tasks. In others, less so.

But the key thing is that the daily standup is NOT a status report for
management! That should not be its purpose! It is for the team members to sync
with each other, not a daily report for task management.

~~~
ownagefool
I don't disagree and for the record I'm an engineer. I don't think my points
are actually counter to yours. :)

------
BigJ1211
Don't agree with this assessment at all, we do stand-ups and it rarely takes
more than 5 minutes. It help immensely with production as your colleagues
often help keep things from falling through the cracks. (I.e. someone forgets
something). Or they might be able to help you out, or further along because
they've done something similar. When they do, you don't do it during the
stand-up to not disrupt that.

Overal I don't think it's disruptive at all to do a short stand-up, constant
nagging however is very disruptive. That person that just walks in or starts
spamming you on slack takes more time altogether per instance than a single
stand-up does. It takes you out of your process, you then have to pick that up
again. If you're working on something complex that can mean it takes an
additional 10 minutes before you're back on track. That's the kind of
disruption stand-ups can help prevent.

This of course only works if you actually stick to what the stand-up is meant
for.

~~~
mcv
It's a bad article. Standups shouldn't be disruptive at all. Just a couple of
minutes to get some idea of what everybody is working on. Standups are in my
experience much more effective at signalling blocking issues than slack.
Nobody is going to spend their day checking what other people are doing on
Jira, so the standup is the perfect time to inform everybody efficiently.

If any issues come up, you can discuss them immediately after the standup.

Long meetings are terrible, but short meetings are great. That's the whole
idea behind the standup. If a couple of minutes per day kills your velocity,
as the article claims, I wonder what else you're doing during the rest of the
day. It only has a measurable impact on your velocity if you're only a working
an hour per day. And even then I'd guess it's useful to have a quick refresher
about what you're working on.

~~~
gridlockd
> Standups shouldn't be disruptive at all. Just a couple of minutes to get
> some idea of what everybody is working on.

 _That 's disruptive!_

> Standups are in my experience much more effective at signalling blocking
> issues than slack.

If you are using Slack, you have already lost the battle for productivity.

> If a couple of minutes per day kills your velocity, as the article claims, I
> wonder what else you're doing during the rest of the day.

Literally any interruption destroys your focus. A pending appointment destroys
your focus. If you use Slack or E-Mail notifications, people never even attain
focus, so in that sense it's not a loss.

> And even then I'd guess it's useful to have a quick refresher about what
> you're working on.

To a first approximation, nobody cares what you're working on. Nobody should
care what you're working on. If your developers need to constantly communicate
with each other, something is likely very wrong with the way you split up your
work.

Daily standups pre-suppose that there's always stuff to communicate and that
everyone is always involved, but only once a day and only briefly. This is
complete nonsense. You need to be able to adapt to the situation. You need a
meeting? Have a meeting with whoever is concerned. Have a follow-up meeting.
Take your time and _focus on the issue_ , then nobody will even feel like time
is being wasted.

~~~
mcv
This sounds like an argument for having a single stand-up meeting instead of
communication through slack and email spread throughout the day. It keeps the
disruptions concentrated in a single, predictable moment.

> _" To a first approximation, nobody cares what you're working on. Nobody
> should care what you're working on."_

I care quite a lot what the people in my team are working on. Otherwise why
are we even a team?

If you're not in a team, obviously things are different.

> _" If your developers need to constantly communicate with each other,
> something is likely very wrong with the way you split up your work."_

It's the opposite: if developers are not communicating, they're probably not
cooperating with each other, which means something is very wrong.

~~~
gridlockd
> This sounds like an argument for having a single stand-up meeting instead of
> communication through slack and email spread throughout the day.

It's an argument for having meetings when you need them, with whoever you need
them with, with no particular schedule or routine attached.

> I care quite a lot what the people in my team are working on.

Do you really? Or do you just want to signal that?

> Otherwise why are we even a team?

You are on a team because that's the unit of organization above the
individual.

> It's the opposite: if developers are not communicating, they're probably not
> cooperating with each other, which means something is very wrong.

If developers need to cooperate, you have a problem that you should avoid at
great cost. Of course, sometimes cooperation is unavoidable, but it's not a
good thing in and of itself. Don't let anyone tell you otherwise. Aim to split
up your work to require minimal cooperation. This may sound like
unconventional advice, but anyone with enough experience managing developers
will likely agree.

------
Traubenfuchs
Daily standups are often a panopticon for those who mine story points and
their wardens that micro manage them. Anyone not coding (RE, BA, managers of
any kind) usually don't need to justify their contributions to the team. It
fits extremely well in the story point driven "agile" world where working on
stuff that does not provide immediate business value, like code quality and
technical debt, is highly discouraged.

I have seen so many dysfunctional standup cultures: Places where you had to
showcase and exaggerate how much stuff you had to do and people were looking
at you funnily when you said what you are doing in under a minute, places
where discussion that only interested a third of the team were started and
standups took half an hour, places where the managers interrupted and asked
why stories took so long...

~~~
tracer4201
I’ve worked at two of the FAANGs, and some of my teams had daily stand ups and
some didn’t. Some teams had stand ups but didn’t track points or velocity of
any kind. Others did.

When we were working to disambiguate deliverables or working on design or
implementation, stand ups were useful. They held everyone accountable, when
folks weren’t making progress because of some issue, it was super obvious - it
gave management a really good insight into where things are and what blockers
are.

Your characterization certainly doesn’t represent my experience. We went
through phases of launching a products or services and focusing on them and
then going back to pay off some of the tech debt until product management,
engineers, and leadership arrived on the next set of big features.

------
mstaoru
Standups hurt more than help. As someone who managed fully remote teams in the
past, what worked very well for us is a set of rules around in-house built
task management system (something like Jira could work too).

1) Aim to take 2-3 tasks, do not take more, take 1 if the task is large, but
usually, it's a sign of an overblown story.

2) Every day at the end of the day, write a "current status" comment. These
comments are visible in the master panel, and I could take action the next day
to help developers resolve roadblocks, if the resolution is taking longer,
they can work on other tasks they claimed.

This effectively eliminated the need for standups, the whole team could sync
using task "current status" updates, and chime in with help or advice. I was
able to see the progress and issues without forcing people into a mess of a
video call, and everybody could still stick to their preferred schedules and
have personal lives.

~~~
mywittyname
This is my preferred method as well when leading a team.

Standups as intended are too brief to discuss the important details. This is
why they end up ballooning to 30+ minutes at most companies, because anything
shorter is of little value.

They also end up as a catch-all meeting for any topics that require the team's
input; I dislike this because people are expected to provide input on the spot
without really making any thoughtful considerations. If we want to have a
discussion on a UI component, that should be done in a dedicated, prepared
meeting, not at 8:30 in the morning when people are unprepared and said
developer can take advantage of unpreparedness to obtain the consensus they
want.

When I provide up-stream status reports, I like to have the developer's notes
in front of me for a quick refresher. Plus, they serve as a good reminder on
topics that need followup.

------
Quarrelsome
Ours take 10 minutes, we use them to update people on how our work item is
going (e.g. if smth is taking longer than expected) and specifically to give a
sense of citizenship and culture. Otherwise we might as well remote in from
various corners of the globe in shadowy rooms and talk using voice modulators.
Sure, not everyone works like that but I personally like to put names to faces
and gain a sense of personality behind the names in a git blame.

If you don't value those things then just be low key in your input, its
literally 10 minutes of your day and has the potential to present an avoidable
issue. To discard it as "management trash" is IMO a massive amount of
disrespect toward your fellow team members. They can help and the stand-up
opens opportunities for help. There's design work, review work, product
management work, scheduling, triage, retrospectives. There's ample
opportunities for efficiency gains in these areas during a stand-up outside of
just writing code. If you think your job is just writing code then I can see
how you might think they're useless but nobody's job is, we all work in teams.

~~~
lawn
> its literally 10 minutes

Even if the meeting itself was instant it would take more than 10 minutes. You
would have to stop whatever you're working on, even if you're in the middle of
a valuable flow state. Then after the meeting you have to get back into
whatever it was, which alone can take you more than 10 minutes depending on
the depth of your work.

If that's not bad enough then what you talked about in the meeting can also
linger. You'll think of problems others have had and it causes your mind to
lose focus, now you have thoughts about your problem mixed with other
problems. These meetings also tend to happen during the mornings, smack in the
middle of the most productive hours of the day.

No, a daily standup takes much more time than 10 minutes.

~~~
jsutton
You should be able to figure out a good daily time for your team that doesn't
involve breaking out of the middle of a flow state. Maybe when everyone is
expected to be in the office, or even right after lunch?

~~~
lawn
The risk is always there. Say you schedule it at 8 in the morning? Then you
might interrupt the people who come in earlier. Schedule it before or after
lunch? Unfortunately people eat lunch at different times too. Schedule it at
the end of the day? Then the daily standup loses it's effectiveness (while you
risk interrupting people who flow later in the day).

------
JaumeGreen
Daily Standups do make sense to some.

In an ideal world everyone would be perfectly professional and not need any
supervision at all. In the real world some times you might be in a rough
period or have some other problem that makes concentrating hard. In an ideal
world the thought of getting a paycheck would be enough motivation. Sometimes
it isn't.

A daily standup, if done well and short, helps one to focus on what's
important, sets the tone for the day, and unites the team as a tribe.

When one is not motivated enough by looking a big fat dashboard with tickets
pending, or the though of getting another paycheck at the end of the period,
one can be motivated by the thought of not failing to their tribe, their
peers, their coworkers.

You gave them your word, face to face, that you would work on something, so
you better do, they are your people.

~~~
kelnos
> _A daily standup, if done well and short_

That's the rub, though. Despite best intentions, sometimes things just go off
into the weeds. It happens more often than I'd like, and it's happened on
every team I've ever been on, at every company I've ever worked at. Sure, you
can say, "well you're doing it wrong", but that's not helpful. Process should
support how the team works, not define how the team works.

> _helps one to focus on what 's important_

If you need to refocus someone every day, you've made a bad hire.

> _sets the tone for the day_

That's _my_ job. I know what I'm supposed to be working on, and set my own
tone.

> _and unites the team as a tribe_

Ugh, gross. We're not a "tribe", "family", whatever.

We're a team of co-workers working on a variety of tasks, who are not children
and can be trusted to communicate adequately with the rest of the team, and
honor our commitments. If you have someone on the team for whom that's not the
case, again: you made a bad hire. Don't punish the rest of the team because
you have someone who can't do their job.

I get that some people get off track sometimes. It happens, even to the most
senior of people. The solution to that is called _management_. Regular 1:1s,
making sure your team keeps their tickets updated, and getting regular
(individual, asynchronous, as-needed) status updates. If someone is having an
off day, or an off week, that should be addressed individually, not by
preemptively assuming the worst of everyone on the team and instituting a
daily standup.

~~~
hamilyon2
This is closely related to one's self-assessment and the question of being
right and doing right thing.

If one is right, stand up do not matter. If one is wrong, they help greatly.

You say : why should I suffer for unprofessional and weak team member who is
wrong?

But you forget to note that the same person could be right sometimes and doing
great things and be utterly wrong and solving wrong problems some other times.

Edit: a also wanted to add, that input from peers and peer pressure is not to
be underestimated. Management is be wrong as often as any of us.

~~~
kelnos
> _But you forget to note that the same person could be right sometimes and
> doing great things and be utterly wrong and solving wrong problems some
> other times._

No, I don't forget that, and in fact specifically addressed people having an
off day, week, whatever.

------
sorich87
I think what you're against are the sync daily standups, not the async,
usually written, ones.

If I was an employee, I would prefer you to let me self-manage my work however
I feel comfortable using whatever tool suits me and my team, instead of
constantly interrupting on Jira, Trello, etc. And I'll keep you updated at a
frequency we agreed on (daily or weekly).

It's also great to read daily updates of others on the team, and even other
teams, to learn about what they're working on without having to check at
multiple places or interrupt their work. It's usually a great way to discuss,
give and receive feedback, asynchronously.

Also, it's strange that you're suggesting "reach out on Slack" as an
alternative. Doesn't that promote the "incessant messaging that Slack allows"
you're decrying at the start of the article?

Disclaimer: I'm cofounder of the team communication tool
[https://www.happierco.com](https://www.happierco.com)

~~~
debt
That’s my biggest gripe with stand ups. Management has as much if not more
access to all the project management tools the developers do, so if they need
a daily standup they should be able to get a sense of what’s going on simply
by correctly using the tool.

------
sanitycheck
I've had daily standup calls spanning multiple time zones (US, India, UK) with
30+ people in which take an hour.

I've had in-person standups which regularly turn into design meetings between
two people, which everyone else has to listen to for half an hour.

I've had 5 minute 9:30am daily standups which always start between 5 and 20
minutes late, thus are significantly disruptive. Arrive at 9, get a drink, try
to pick up where I left off yesterday, oh it's time for the standup. Not yet?
OK, where was I? Oh now? But Dan is on the phone? Alright, in 5 mins? ...First
hour of the day down the toilet.

I've had standups where people are told off for trying to communicate any sort
of useful information - so people just list the people they need to talk to
that day.

And of course in a small company there might only be 8 developers, often
working on 4 totally separate things for different clients, but there has to
be a standup with everyone just because management can't figure out how to use
Jira properly.

I've had enough of standups. I've switched to working afternoons only for my
current client so I can avoid the bloody things.

------
antoinevg
How about we just stop generalising across each others projects, teams and
environments?

This stuff is always highly context dependent and the ongoing efforts of
everyone to pretend it isn't makes it extremely difficult to have adult
conversations on the topic.

~~~
vfc1
The use of unnecessary daily standups is an industry-wide practice that few
teams escape, and it's important to talk about their general unusefulness and
hidden costs.

It has been proposed originally as an agile "let's do what makes sense for
each case" practice, and as quickly been adopted by companies as a common
micromanagement practice.

Yes its context-dependent, but at the same time, its something so pervasive
that most developers can relate to it and have or will experience it one way
or the other.

------
kelnos
Completely agree with this. It just seems like ritual for ritual's sake. I
tend to learn nothing from standup that I couldn't learn by checking Jira or
just directly asking someone. And waiting a full day to raise blockers is
foolish.

Sometimes things go a bit too far, with people delving too deeply into
whatever topic, with a sort of side-conversation starting. Yes, these people
should "take it offline", and often after a minute or so of back and forth,
they will, but it still happens often enough that it turns into a waste of
most of the team's time. "Be more disciplined!", you say? Sure, ok, wave your
magic wand and make that happen, please.

The counter-argument I usually hear to anyone who wants to get rid of standup
goes something along the lines of: "but it's great to get everyone together
once a day, and sometimes people will spontaneously learn of something that
they have useful input for, and save someone some time". Ok, so you want to
waste 10-20 minutes of my time on the off chance that someone _might_ randomly
have a useful contribution that wouldn't otherwise come up? No, pass.

And regardless, this sort of attitude is actively hostile toward remote
members of the team, who may be in different time zones and can't reasonably
participate.

If your team really needs daily status updates, create a "standup" channel for
your team on Slack (or whatever you use), and have people do a once-a-day post
in there. No deadline, just when they get to it. But even that just feels like
micro-management.

~~~
lispm
> waiting a full day to raise blockers is foolish

that does not make sense. Just because you have a short sync meeting once a
day, it does mean should should delay all work until then.

~~~
kelnos
I'm having trouble parsing the last half of your sentence, but I'm going to
assume (please correct me if I'm wrong here) that you meant:

"Just because you have a short sync meeting once a day, it doesn't mean you
should delay all work until then."

And yes, I totally agree! If you're blocked on something, you should raise it
immediately, so you're not delaying all work until your next standup! If you
do have _other_ work to do, you should still raise the issue immediately,
figure out who should own the blocker (if it's non-trivial, your manager will
likely find ownership for you), and then move onto another task until the
blocker is resolved. You gain nothing by waiting until the next day, and
possibly exacerbate the problem if you do wait.

------
Fiahil
I like standups. They keep me updated on what's happening in the code base,
and give us the opportunity to discuss what's going to happen next. The repo
is vast and we're gown adults that don't need to be micro-managed because
story A or B is taking too long.

The problem doesn't come from standups, but rather from dysfunctional startup
culture.

~~~
antisemiotic
I have a similar experience. Standups keep me at least vaguely informed on
what other people are doing, provide an opportunity to take the pressure off
poor souls buried under a new influx of tasks, and are perhaps some light team
building (such as the canned joke that a burndown chart isn't supposed to look
even remotely like that, or something in the lines of "help me, those goddamn
morons from $OVERSEAS_BRANCH at it again"). 10 minutes tops, and back to work.

If I were to compile a list of workspace annoyances, even the most pointless
standup would be way after serious business like "people standing behind my
back while talking to someone".

------
yakshaving_jgt
What information does a standup monologue convey that couldn't be expressed
more clearly and with persistent links to context than a comment on a Trello
card?

My team don't do daily standups. They're pointless ceremony.

Yesterday I worked on… Yes we know. We can see the Trello card you worked on.

Today I am working on… Yes we know. We can see what you've currently assigned
yourself on Trello.

I am blocked by… Why the hell are you waiting until _now_ to bring this up?!

~~~
onion2k
_I am blocked by… Why the hell are you waiting until now to bring this up?!_

...because, as the author of the article notes, developers don't like
interruptions.

You can't have it both ways - either you can have distraction-free work time
so issues like blockers have to wait until the next scheduled communication
time _or_ you get distractions when important things happen. You can't
reasonably state that people shouldn't interrupt you _and_ they shouldn't wait
until the next meeting to tell you stuff. Those things are opposed to each
other.

~~~
yakshaving_jgt
> You can't reasonably state that people shouldn't interrupt you and they
> shouldn't wait until the next meeting to tell you stuff

You _absolutely_ can, and we do it _all the time_.

You didn't interrupt me by replying to my comment here. If I was busy working
on something, I wouldn't have read/replied to this right now.

If I am working on something, it's highly likely that I'll be finished and
take a break to check what else is happening in the team _well before_ a
morning meeting the following day.

If something is truly time-critical and deserving of interruption, then its a
moot point.

------
seibelj
The hubris of the software profession never ceases to amaze me. You have
thousand-word screeds about the injustice of being required to attend a daily
15 minute meeting to catch up with your teammates, while being paid six figure
salaries. I suggest getting a job in food service, or even construction if you
want to see how the average laborer works. Tech is the softest industry ever
created.

~~~
Uhuhreally
oh this one. "X isn't as bad as Y (where Y is worse) therefore X is OK, deal
with it"

X and Y are completely unconnected and X is still bad and should be fixed.

Imagine if you went to the doctor with a fractured ankle and they said "well,
it's not as bad as this baby I saw last week who was dying of sepsis. I
suggest you count your blessings and deal with it"

And 6-figure salaries ? choose the value from the tail of the distribution to
support your argument why don't you

------
asplake
I've long been sceptical of the three questions – well intentioned no doubt
but way too prone to becoming an unhealthy exercise in individual self-
justification. Much prefer to review the work "right to left", starting with
work just completed, then work we can get over the line, then the bulk of
what's in progress, and (if there's capacity), what's in the immediate
pipeline. Now it's about what _we_ can do to finish the most important of
what's in front of us.

------
jimbob45
They're called standups for a reason: you're supposed to do them standing up
so that people whine if they go over five minutes. That tracks out to 25
minutes or less than one-eightieth of your week.

~~~
colinhowe
Except if you're already deep into work because you start earlier than
everyone else then they just rip you out of your flow.

They also tend to be longer than five minutes in terms of herding people to
them etc.

~~~
thawaway1837
The deep flow disturbance can be caused by any sort of communication. So
basically, that’s an argument against communication, as opposed to being an
argument against standups.

If anything, by being at a fixed time, either at the start, or the end of a
team’s day, it’s far easier to prevent a standup from disrupting deep work
than a Slack message would be.

~~~
zorked
You know it will disrupt you so you never even start the deep work. Victory!

------
romankolpak
Daily standups while being mostly useless on the surface, have an implicit
value of enforcing a daily face to face communication between team members who
work remotely. In remote teams I often find that people who don't interact
face to face frequently, but work on the same part of the system, are more
likely to run into communication problems down the road - doing duplicate
work, passive aggressive attitudes in PR reviews, poor communication in
general which impacts the system in a very direct and negative way.

Here's a thing -- people rarely become friends over email or slack
conversations, unfortunately. And a team of friendly people who trust each
other and communicate efficiently (e.g. feel absolutely comfortable setting up
a quick video conferencing call to talk about an issue) is a lot more valuable
than a team of people who rarely talk to each other and mostly prefer texting
over anything else.

Those are my findings when working with remote teams only. I don't think
standups are necessary for colocated teams, which can sync at will anytime
they want.

~~~
segmondy
Exactly. I have some remote folks on my team, and folks rotate in and out of
being remote on a daily basis. So we do that, but I renamed it to "daily
status" since we are not standing up and no one is. We conduct it all 100%
over the computer, so those remote don't feel left out. We keep it on track
and for us we do it right after around lunch. So people have things they have
worked on for the day and things they need to do after. Doing it in the
beginning of the day forces everyone to come early defeating flexible time.
Doing it at end is the same, and if you're blocked it's silly to wait till the
end of the day to tell the team. It's just another tool in the box, if it
works for your team great. if it doesn't, shed it. Attitude can determine how
useful things are.

------
1337shadow
Well, I see the point of a senior: with enough practice you should not need
rituals of this kind anymore.

Some seniors don't even need a kanban board on a fast moving project, they
just know what needs to be done now to create value at lowest cost, they just
feel it.

It's not like when you're junior, you've never done any standup and you don't
know when you've been blocked long enough to switch task or ask for support,
you've never done any poker planning if you're techie, or value estimations if
you're product / sales, you've never prioritized by complexity / value score
if you're manager - or equivalent.

For this reason, I think there's still value in such rituals when there are
non seniors in a team.

However, I prefer text-chat based standups myself and feel like they produce
the same value and cost less time.

~~~
matthewmacleod
_Some seniors don 't even need a kanban board on a fast moving project, they
just know what needs to be done now to create value at lowest cost, they just
feel it._

These are always the worst people to work with, because they think they know
much more than they do.

Frankly the most difficult parts of effective engineering are nothing to do
with software and all to do with good team communications.

~~~
1337shadow
I'm sure sure we're talking about the same things: __not __communicating daily
is obviously going to be a problem, such as __not __giving the team a chance
to change your priorities.

But a senior knows basic needs for a product to live on like stable
production, continuous integrations, unit/functional tests, code reviews,
continuous deployment, infra & application monitoring, alerting, backups,
service & dependency versions upgrades, fix regressions introduced by new
features, with test ... and all sorts of quick wins for the product that come
out of a casual discussion with a product / sales person etc ... The kind of
usual things that becomes a daily routine and may just take the day to the
point where you couldn't move any new feature card in the kanban anyway.

Is it necessary to create a kanban ticket every time they do a package update,
fix an impediment or do something in 0day ? It can surely be useful, not sure
if it's more useful than just reporting on a text based chat, can it be
harmful by polluting the kanban with tickets that don't create any obvious
value (tech debt treatment) ? as long as communication goes through it's fine
with me unless someone wants to build a report at the end of the month (ie.
billing), I believe the practice matters more than the tool.

But I'm more trying to understand the point of this article, searching for
conditions that would validate it, rather than defend it in all case.

For me daily communication and the three questions are important (but I prefer
async / text based, and even twice a day: when I check-in and check-out), for
the rest it depends, I can understand why some seniors would feel like blindly
applying procedures may seem un-necessary or harmful sometimes, like they say
: it's the dose that makes a cure or a poison.

------
mosselman
The questions as presented strike me as something that is more suited in a
1-on-1:

> What did I work on yesterday? > What am I working on today? > What issues
> are blocking me?

At my job we have tickets on a physical board and we discuss them from right-
to-left. There are magnets on the tickets with people's names on it and when
you get to 'your' tickets you talk about what is happening with that ticket.
This is a lot more concrete and relevant to the rest of the team.

At a previous company we went from person to person and they'd discuss what
they were working on. This always struck me as a strictly personal accounting
of their previous work day and I had a feeling that people felt like they had
to boast or exaggerate what they were working on. It never felt relevant or
interesting.

------
dagw
In my limited experience, one key to successful standups is making them as
small as possible. The worst standups are the ones which contain over a dozen
people working on a bunch of only vaguely related projects. The best ones are
the ones that only involve the people working on things directly related to
thing I happen to be working on. I you're a manager this might mean that you
have to organize 3 or 4 standups instead of just one and keep track of who is
working on what and being sure the right people show up to the right meeting.
If it turns out that someone is being blocked by someone not at the meeting
then either set up a new meeting with just the people involved in that problem
or make sure that particular person is at the next meeting.

------
bengale
> I've had this feeling that the industry likes to treat development teams
> like a bunch of idiot teenagers.

The infantilisation of developers seems to be common in larger organisations.
It's extremely tiring.

~~~
rswail
The infantilisation of _all_ workers seems to be common.

The stupidity of terms like "tribes" and "squads", the endless gamification,
the "open office to encourage communication", the discussion of "learnings"
and other verbed nouns.

The only people that it suits are HR types that love that everyone can be
_seen_ to be working together and the management that save lots of money on
real estate and infrastructure costs.

Sure, breaking down company silos is a Good Thing. Orienting people to work
across disciplines and be focused on the customer is a Good Thing.

Inventing crap like standups (the Queen does them for Privy Council meetings,
works for her), and titles like "scrum master" is just as bad as the "black
belt 6 sigma" of the early 2000s and the other management fads.

------
andygeers
I work in a fully remote team and our daily standups are one of the highlights
of the day as we get some actual "face to face" time rather than just the
usual Slack chat. I think it's probably a bit reductionist to use a headline
like "Standups are pointless" rather than just "I've personally not found them
helpful".

------
bengalister
For me daily scrum meetings were valuable when the team remains small and work
on related stuff in a fast pace.

But for the last few years, it has not been the case for me. Standups have
been organized for managers and scrum masters so that they attend only 1
meeting and participants were not working on directly related topics. Most did
not care about what others were doing and issues they faced. We reduced them
to bi-weekly or 3 times a week and re-focused them on synchronization
topics...

Also my general feeling (maybe because I am an old developer) is that it is
infantilizing, and a way to maintain peer pressure.

------
TallGuyShort
>> Okay so, basically, the only unique point to standups is that they "keep
everyone excited"?

Skipping right past the part about "flag team blockers" in what they just
quoted. I don't much care for the other nonsense, but sometimes I'm stuck on a
problem, and I'll keep working on it if no one else knows, but it's nice to
just broadcast where I'm at and see who thinks they have helpful insight. That
happens a lot in my stand ups.

~~~
scruple
Do you not have async channels for this? I've never thought to myself, "Well,
shit, guess I'll keep banging my head against this problem until I can get
some help in tomorrow's standup." I have a hard time taking that seriously.

~~~
TallGuyShort
That too, but do you find that everyone in the team eventually reads
everything on the async channel?

~~~
scruple
I tend to, as a team lead, yes. There's also @ mentions in things like Slack
or regular old email to get people's attention.

~~~
smileysteve
"As a team lead, yes";

1 goal of scrum is to allow the team to function, to avoid having a single
point of quarterbacking, and messages going up and down a chain of command.

Moreover, from a psychology perspective, the act of reaching out for help
require significant humility and is often delayed.

As a lead, I've found it useful to be able to ask questions about updates,
and, demonstrate "quarterbacking" by delegating myself or other to pair or
split work off. Sometimes it's to ensure that there is better shared knowledge
gained, sometimes it's to better parallelize work.

------
frenchman99
Working remotely, the daily standups are the only times in the day where we
meet up face to face in a video call.

Not only that but it's a time where we feel safe to say that we are struggling
on something and ask for help to everyone at once: this often leads to someone
in the team (not necessarily the manager) suggesting a pair-programming
session to move forward more quickly.

Another thing is that we have several products developed independently but
with shared libraries. The standup is the moment where we suggest appropriate
usages of the shared libraries depending on what our teammates are working on.
This increases code re-use and makes us faster.

In addition, we have what we call "Sharing time" at the end of our standups,
which is a time dedicated to sharing anything we care about, mostly non work
related. It's actually cool to see what our colleagues are up to outside work
(one colleague is into model planes and 3D printing, another is currently
traveling across Portugal, etc, etc). Very interesting stuff !

Our daily standup is kind of like the coffee break in a traditional office.

------
fnord123
This type of article has far too broad a brush. It's like saying don't play
4-4-2 in football (soccer) because we just won a trophy using 3-5-1-1 so 4-4-2
killed your team's chances of success. It's so small minded it's incredible.

As a manager or as a team, you need to determine what will work best for your
team and you will need to adapt.

------
ritchiea
This is absurd to me. Standups are quick and it is helpful to know what
everyone is working on. And they can serve as a time when you are up front
about being stuck on something and get some help from a teammate when maybe
otherwise you might have just kept tinkering or hammering away in your own
world. It’s just a little nudge to share your status and keep everyone on the
same page. It prevents wondering what your colleague is typing up a storm
about which is a natural human curiosity.

And the author says make it async, I agree! That’s not against the spirit of
standups, I’ve worked on remote teams with an asynchronous standup slack
channel.

The most common problem I’ve seen with standups is they can become more than
status updates and end up a time during the day to brag about your
accomplishments or justify your status within a team/project. Usually to keep
management happy or angle for an agenda other than keeping the team together.

------
xborns
Yes, distractions are not great - but communicating with your team is
important. Even if the manager is not there the team does it and they do it
usually < 5 minutes. Some days I literally don't talk to my team except for
that 5 minutes.

But as a leader you want to make sure the team is rowing the same direction -
it doesn't matter if it takes you longer on a ticket but it also helps in a
team to know what others are working on in case you end up working on it later
yourself. (We discussed at standup to implement it X way because of Y
factors).

Many engineers (myself included) don't like asking others for help. But guess
what when someone says they are stuck - it is easy to point them to a person
or direction and not waste time debugging a problem already solved in the
past.

If they were so horrible and unproductive, managers (who mostly were engineers
in the past would get rid of them).

------
czbond
Yes, daily detailed standups are not useful. BUT, since development teams tend
to be slightly to very introverted, it helps ease 'department wide'
communication and 'solutioning' that wouldn't happen otherwise. The underlying
goal is to help personality types that often don't like to communicate outside
of a small group, and often don't like to ask for help, and in some cases
helps the few developers who 'cannot see the forest for the trees' that focus
on trivialties when they need to look past them. Edit: It also helps product
or leadership types who may not be well versed in technology.

~~~
therealdrag0
This is where I've seen value. Building comraderie/comfort within the team,
where otherwise devs might not talk to each other. Provides a sandbox for
brainstorming/reviewing strategies ("Oh did you try this framework/class" or
"oh I wrote the same code in X service 4 months ago, go take a look) and
making sure everyone is on the same page about what is going in the next cloud
release.

I will say that only 2/3 times a week is the best bang for your buck, and
often switching to "Slack-up" instead of "stand-up", when people are busy with
other things or can't be bothered.

------
arkh
Move the daily to just before noon: it does not stop you during work and
people tend to keep it short because they're hungry. And you can have people
coming in late in the morning and not be a problem.

They're a good way to handle people who don't communicate well: if it looks
like a junior is blocked on something and does not like to ask for help
another dev can easily propose a pair-coding session.

But you need to only have devs or former devs so you don't get the feeling you
get judged because your "what have I done last day" is "mainly nothing, this
ticket is not exciting so I'm going slow".

------
stephc_int13
I can't agree more. I've never done standups in the teams I managed.

But I chuckled a lot when seeing other teams/companies destroying the morale
of their employees with this childish and borderline cult-like parade.

------
Ensorceled
I've taken over management of a few scrum teams now, and in every case, I've
also had to take over standups. One team had somebody who used a time tracker
and showed me that the average length of standups before I arrived was
something like 37 minutes. Another team, standup was run by the PM and they
reviewed EVERY story in the sprint, triaged all new bugs, talked about new
features and, worse, pressured developers who were falling behind at EVERY
standup.

Given how badly many standups are run, I completely understand why most
developers hate them.

------
jake_morrison
I am a consultant working in a distributed team, often remote from our client.
I find the standup format to be very useful, often delivered via a daily
email.

While we use a formal issue tracker like Jira which handles approvals and
estimates, from a project management perspective it's useful to have a summary
email that is short enough for people to read and focused on business level
issues.

"Today I worked on this" / "Next I plan to work on that." This helps clients
to see exactly what we are working on. It avoids miscommunication where we
think they told us to prioritize something different, or they thought they
told us to stop work on something, or they think we are finished with
something and we are not. Having an email every day lets them tell us to stop
work immediately if we are doing the wrong thing, avoiding surprise invoices
the next month. It avoids them claiming that they didn't know that we were
working on something.

"Here are the problems I am having / things I need from you". This is very
useful to keep track of delays caused by the client. This might be them
needing to review and accept work, review specs, or pay their invoices. Issues
stay on the report until they are resolved. It documents that we didn't get
what we needed, so we can't be blamed for things being late.

------
aazaa
> Jira, Trello, Asana, the stickies on your wall, or reach out on Slack

In a nutshell, the article claims that these electronic tools render a daily
standup pointless and/or disruptive.

First, note how many different tools are mentioned. If your project uses one
or more of them, you'll need to monitor them all to understand what's
happening around you.

Second, the constant interruptions of Slack can be extremely disruptive to
workflow, as has been noted in a few articles posted here.

Third, the article makes an assumption I've seen elsewhere and cannot relate
to at all: that project members don't need a high-level snapshot of the
project on a day-to-day basis. That it doesn't improve what they do and only
sucks time away from the more important job of getting stuff done. As the
author puts it:

> I'd argue the loss of your focus more probable than the benefit of knowing
> what someone else is working on.

This is a recipe for the entire team heading off a waterfall, each in their
own hermetically-sealed, technologically sublime barrels. This is not to say
that a daily standup can save you if the team is determined to do it. But
getting that daily overview can help build consensus for changes in direction
that simply can't come about by monitoring Jira.

I always wonder how effective team members showing the tendency to minimize
the bigger picture while maximizing the importance of their own contribution
will be on a team. The answer usually turns out to be "not very."

------
tudorizer
I strongly disagree and would like to apologise on the behalf of devs +
managers that gave you this impression.

I was fortunate to work with people that ran proper stand-ups (5-15 minutes at
the beginning of the day, actually standing up). Senior, junior, management,
devs, it felt like we all benefited from a quick huddle before starting dev.
Even if we Slack troughout the day and raise issues, having a quick sync
session seemed to have a bigger impact.

------
obfk
Agree with the notion that turning standup into a static status meeting is a
poor use of time. If you're blocked you should speak up. If the team wants to
know the state of your work, they should defer to project management tool.
That said, "standup" is less to do with what you did or immediate blockers.
It's about planning for the day. "Here's what's going to get done today, and
here's the relevant information for my team." It's a tool for synchronizing,
getting on the same page, setting you and your team up for success on a daily
basis.

If you don't feel like that's the case, you're probably right in that going
async _would be a better use of your time_. I suspect this is a process
dysfunction that has less to do with standup and more to do with a
misunderstanding of the value proposition associated with a properly executed
standup.

Edit: not everything is an immediate "oh sh*t" type of blocker. If you're
working in a collaborative organization, you most like have "low tier"
blockers or knowledge that can and should be shared with the team. Face to
face makes this easy.

------
jcutrell
I get the frustration, I really do.

But I think part of the issue here is the idea that time is fungible like
money. That saving time by looking at Trello cards instead of meeting face to
face is somehow more effective.

It might be. It might not be. But simply saving a few minutes of time doesn’t
necessarily equate to “more productive.”

This kind of optimization of behavior assumes everyone will consume
information uniformly.

Ever sent up a smoke signal for help on a blocker in slack, only for the
comment to be lost in a bunch of messages and you stay blocked?

Again, in a perfect world, we could just record everything and do it all
asynchronously. Wonderful ideal.

But the stand up, in my experience, accomplished more than just cold task
management.

It gives a point for each person to consider what they’ve done, compose it,
and to raise in a higher resolution environment the blockers they have.

It’s silly to think that we can replace every interaction with an async
version of the same interaction, at least on my team.

At the same time, I don’t recommend dogma in either direction. Don’t find
value in the standup? Do something different.

------
disposedtrolley
I've had no issues with standups. Even in a small team I find them useful as a
way to step back and see the bigger picture, plus they rarely take more than
5-10 minutes of my morning.

On the other hand, I've had friends who have endured 30 minute standups every
day for the past few months. I think they started sitting after the first few
sessions.

------
NalNezumi
As a fairly new out of university and with my first startup job, I found the
newly introduced daily standup a motivation saver & reduced stress in the
group.

Our dev sub-group had no sync-meeting except weekly-meetings where we met the
entire department that presented their progress that didn't give us any
insight in what was going on at all. Didn't help that our sub-group
responsible where the CTO, that was mostly absent for
investor/customer/management meetings. Tasks where distributed really
unevenly, some devs got isolated in their module/tasks for week/months and
lost sight of where the development was at the moment.

standups seems to work pretty well when the person in charge have insight in
to how each members work fit in to the overall picture, and would rather not
manage the group much more than making sure people are not trailing off. It
helps the group more than the managers, if done right.

------
bigpeopleareold
Daily standups are not useful to me, but having just a periodic conversation
with who you work with is more useful that both just standups and/or just
checking issue lists.

A lot of times, there are plenty who simply don't talk about the projects they
are working on unless prompted. This extends even to JIRA tickets, which can
feel like bookkeeping than actual work. For me, this tends to be a constant
problem, but adding more layers of protocol tends to scare people more than
anything. This can be like a fear around saying you couldn't get anything done
yesterday.

With simple conversations where I can just talk with team members for an hour
or so is more revealing that trying to answer specific questions. The
important thing is not to cover each detail. Instead, for me, is just
conversing about problems where we all gain more insight in what we are doing
that helps a lot.

------
reallydontask
As a grunt, hate them but as a team leader they really help make my life
easier. In short, depending on team size, you are sacrificing the producers to
make the manager's job easier and unfortunately this is a decision that the
manager gets to make, so guess what decision is made all the time.

The problem is that as a manager I don't want to look bad in front of my
manager and he he/her manager's and so on and so forth, so I have to do things
that are suboptimal from a delivery point of view to avoid this, e.g. run a
stand up to keep a close eye on what everybody is working on rather than say
not and ensure that they guys (and gals) know that I'm here to help should
they get stuck.

To be fair, they do help with managing people that are, for whatever reason,
reluctant to look for help, but there are other ways of managing this

~~~
0027
> As a grunt, hate them but as a team leader they really help make my life
> easier.

Have your grunts obeyed their leader?

------
mrkeen
Don't just do something, stand there!

------
jonbronson
In the very spirit of agile, if standups are not providing your team value,
then by all means stop doing them. But, if you are not able to perform a quick
functional standup that informs your team about the important work each person
is doing, their blockers, etc, might I suggest this is a sign of a deeper team
disfuction, rather than some inherent issue with standups generically.

I'd go further to say that if your standups consist merely of parroting words
verbatim from JIRA, you're letting your team down by not providing additional
detail and context that could be provided more easily in person than on such a
tool.

Lastly, reading between the lines of your text, you seem very much "over it".
Not standups, but team engineering. Possibly time to find a new environment
better suited to what you enjoy.

------
lispm
Reducing actual face-to-face interaction and communicating only over Jira is a
way to de-humanize work.

Do work as a team of humans. Talk directly to your fellow team members. Using
daily standups is a face-to-face way of syncing.

Don't work by sitting 10 hours in front of your screen and communicate only
via chat channels.

~~~
Uhuhreally
Jira is the passive aggressive student fridge note system of communication

------
pradn
Standups are only good if they're used for a very specific, time-critical task
that requires coordination among several people. Ex: a major feature is being
launched that requires a lot of coordination, but is going to be done in 10
days.

Standups should not be used as tack-on "agile" or as a way for management to
keep up with what devs are doing or to pressure devs to do more. Ex: daily
standup at 11 am.

The original purpose of standups in "agile" was to help devs get unblocked.
But the expectation should be that others should help devs get unblocked
whenever they hit a block, instead of waiting til the next standup! What are
they wasting time being blocked when they can simply send an email or IM to a
colleague?

~~~
zoomablemind
Indeed, to make a standup more straightforward we usually just fix 3 questions
to everyone:

1\. What are you working on?

2\. Are you having any blockers?

3\. What are you going to work on next?

In reality it's just about blockers and seeing the next direction.

No need to embellish or 'stuff' any of these responses. It was kind of natural
when we used to have a real storyboard, the one with post-it stickies. So the
standup would be a good time to move the stories to done or todo side.

Well, the whole idea kind of sputters when there're significant status
disbalances on the team. For one, the dev members get into status-report mode,
while the managers get into i'm-busy-with-important-meetings mode. For the
other, it's harder for mangement members of a team to align their ways of
staying busy with 'ant-like' activity of devs. Also in such context a
'blocker' suddenly signals a kind of a failure, lack of efficiency that has to
be owned, instead of a usual work issue. Who wants to own a
failure?Ironically, the management can be instrumental in resolving intra-dept
blockers.

Any team is about mutual trust, so if the standup does not serve the needs of
the whole team, I'd just reserve that time to those members that see a benefit
from it. Find another way to interface with other members (mgmt?), maybe a
questions queue or some briefs pipeline.

------
stakhanov
In a recent client engagement I witnessed scrum-gone-badly-wrong.

It happened underneath the department manager in the line organization of a
large corporate (not project manager, line manager). He managed about a dozen
people doing about a dozen projects at any one time. A project was usually
staffed by one person working it fulltime, and drawing support from the rest
of the group here and there.

The manager held a daily standup involving the whole dozen people. With
everybody doing a five-minute status report on their project, that meant five
minutes of speaking time for everybody and 55 minutes of sitting through
status reports on projects that you had zero involvement with, where you
couldn't possibly have anything useful to say. I suggested numerous times that
it would be better to have devs have a 1-hour blocker in their calendar
without an actual meeting. They would do an e-mail update, and if the manager
saw the need for any clarification he could use the 1-hour timeslot to turn up
at their desk and talk 1-on-1. It would have been so much more efficient, but
the manager didn't go for the suggestion.

Paying lip service to the scrum quasi religion, the manager repeatedly
emphasized that the point of the standup was not to check on people's
productivity or make them face repercussions for not meeting daily
commitments. But he never missed an opportunity to make a passive-aggressive
joke when a dev's productivity was called into question. Like a dev might say
"I thought I would be able to do X yesterday, but didn't manage, because
problem Y turned up. I solved Y, but X is still not done". The manager might
jokingly say something like "Well, I hope you enjoyed your beachtime and will
be able to finish X today." So not funny. I'm thoroughly convinced that
shaming people was the method he was using to pressure people into doing
overtime or otherwise doing whatever was necessary to meet daily goals every
day, and that that was the real reason he wanted the whole department in the
room. Because shaming is so much more effective when you shame somebody in
front of a lot of people than just making a bad joke in a 1-on-1 situation.

------
jedberg
I don't know if they daily standup is necessary, but there is some value in
frequent synchronous meetings. Some people just feel more comfortable bringing
things up during a meeting, despite the myriad ways they could otherwise
communicate.

------
philipps
Standups can be great. And they can be useless. It depends on how they are
designed and used. For example, the frequency should be matched to the needs
of the team. It only makes sense to meet when there is relevant new
information. For example, at the Broad institute at MIT, lab teams meet daily
to discuss the output from the last day to identify bottlenecks. It’s
important to identify problems quickly so meeting every day makes sense. In
other systems, meeting every two or three days would make more sense. It’s not
that standups are useless, but that poorly designed stand ups are useless.

------
0x70dd
I had the exact same feeling when we started having daily standups about 4
years ago for a green field project. Now that most of the original developers
are no longer in the company I feel glad that I actually paid attention. It
turns out that I have a very good knowledge about how and what every micro-
service in our stack does. What's discussed in those standups might not be
relevant for day-to-day work, but on a higher level it can help developers
understand the architecture of a complex system better.

------
specialist
_" Your standups are killing your velocity."_

"Velocity"?

It'll be hard to start a revolution while still using the enemy's terminology.

\--

Gods, I'm miss PMI, critical path, the trilemma (time, cost, scope), quality,
rationality.

And before any ankle biters whinge about "water fall", just stop. We were so
much more iterative, nimble back when we acted like professionals.

The Agile Methodology is to argue about the Agile Methodology. Pop-biz
psychology. Tech's own post-modernist rejection of anything older than a week.
And just as useful.

------
amitport
I strongly disagree. People sometimes won't mention important things (e.g.,
blockers, possible misunderstandings) unless prompted and encouraged (you
sometimes actually need to look at the person's face and hear the intonation).
Async interrupts are bad (I don't have time to get into that one right now). I
would have replace "Excitement" with "expectation management", "mental
atmosphere monitoring".

I do agree that badly managed stand-ups are a waste of time.

~~~
ddebernardy
> People sometimes won't mention important things (e.g., blockers, possible
> misunderstandings) unless prompted and encouraged (you sometimes actually
> need to look at the person's face and hear the intonation).

But that's a management fail. Every time I've managed a person that did this,
I took them aside and had a short but firm word with them. You can't tolerate
that type of behavior in a team if you plan to operate effectively. I seldom
need more than one warning; I never needed more than two.

~~~
amitport
The point I was trying to make is that when a person is [inexperienced/shy/too
aggressive/doesn't get along with somebody/lazy/does not like the current
task/does not understand the motivation/etc] I need, as a manager, opportunity
to notice it.

some of those are not necessarily "bad" or require intervention, just
awareness.

some of those can change over time (and on daily basis).

(and in the case of bad behavior, in order to prevent "management fail", I
want to take them aside for that short talk _before_ things get spiraling)

(that being said, it's not the only reason for standups)

(if in my team everybody is in the same place, actually interacting in-person
does give some added value)

------
gamesbrainiac
I completely agree with this. Standups are pointless, you have just
communicate anything that you need to communicate via chat. Standups in
general are simply a pressuring mechanism.

------
combatentropy
I would not mind a stand-up once a week. In fact on a team that never had
meetings, I suggested to my manager to have a half-hour meeting every week or
two. And I hate meetings!

------
sbochins
I usually take note of what I did at the end of the day to give me an idea of
how productive / unproductive I was. On a previous time I got everyone to just
post their standup updates on Slack. It was quick and asynchronous. If you
wanted to follow up with someone you could just talk to them afterwards. It
also gives you a history of the past week, month, etc if interested. Data is
useful and daily meetings are often pointless. Let’s all evolve our standup
routine.

------
thrower123
The only time I have ever seen value in a daily standup meeting is when I
worked in a blue-collar industrial job.

Everybody had to clock in by 6:30 AM, so there was none of this shit where it
is time for the standup, and two or three people haven't dragged in yet, so
you delay and waste time.

The foreman told each person what they were doing that day. And that was what
they needed to get done.

If there was a blocker or a safety issue, you threw the shutoff switch and
jumped on the radio right away.

------
buf
I work remotely, have the last 5 years. I love daily standups. Here's why:

1\. We do all of our work business async. (e.g. what did you do? what are you
working on? All that stays in slack)

2\. We use our standups for ice-breaker questions and company-wide
announcements. (e.g. Everyone talks about what their favorite vacation was,
which usually creates quite the conversation. And then afterwards, the team
heads will give any critical updates they have, which usually are none)

~~~
nerdponx
_Everyone talks about what their favorite vacation was_

Getting to the office "on time" (9 AM) takes an extra 30 minutes compared to
arriving "late" (10 AM) due to rush hour mass transit congestion. I would be
very pissed off if I had to show up on time just to hear about my coworkers'
vacations.

~~~
buf
> I work remotely

I have no commute. Hearing another human being is a welcome change from
sitting in my home office all day.

------
jacknews
it depends on the tone of the standup.

For a start they should be quick, and the team needs to be fairly small (about
5-6 seems ideal). and cohesive, mostly working on related or interacting code.
Also I assume remote, as that's my experience.

The status update part should be extremely quick even perfunctory, unless
there's an interesting lesson or important caveat or note-bene etc to share
with the team.

The reason for the standup is to make sure everything is "joining up"
properly, no new obstacles are looming, and possibly to plan meetings/pairing
sessions/etc, for later that day, where required. ie like a football scrum
where you agree the game-play for the day.

It's also chance for a bit of "team bonding" type stuff, eg to ask the whole
team "are we all feeling good about this sprint", etc - ie, the kind of stuff
that may not obvious from stats

If the standup just becomes a forced "status report", that's worse than
useless, I agree, and just makes everyone feel "monitored" and under pressure.

I would guess they are also less useful (and potentially more stressful) where
everyone is physically present, and might be seen as a trick to get everyone
to the office on time.

~~~
majewsky
> ie like a football scrum where you agree the game-play for the day.

Why do you need to change your strategy every single day? Do your requirements
change _that_ fast? What you're describing is the point of the sprint planning
meeting IMO.

~~~
jacknews
Daily would be tactics, not strategy, and ideally the daily game-plan follows,
and follows obviously from, what was planned for the sprint, in which case the
scrum is just a rubber stamp.

Ideally.

------
mharroun
I come to prefer standup over slack, 10:30amish everyday a 30 second message
of.

-I did x yesterday and am doing y today. \- I am blocked/need a (answer, code review, dependency completed, ect). -reminder of OOO or WFH.

This minor message keeps everyone in the loop and takes little time. If you
feel pressure to deliver because of standup I would say that's a cultural
issue... or a self performance one (aka why have you been working on x for 2
weeks).

~~~
vfc1
It's not a cultural issue, it's human nature. You are being asked about your
performance daily in front of your group of peers.

This will obviously psychologically pressure you to finish things ASAP, so
that you can say that its done on the next standup.

And that is why management like standups so much, I mean why not say what it
is actually for, instead of coming up with all these other side explanations.

------
redhale
> "Maybe its naiveté or maybe just being on teams where, remarkably, nobody
> knew how to do an effective standup (myself included)"

Nailed it. Please don't "ping me on slack" to find out what I'm working on.
And please don't force me to document to the nth degree in JIRA. Let's just
have a quick chat in the morning and move on with the day.

------
LandR
One way of doing stand-ups that I found least annoying was we went through the
Kanban board and basically asked if you had any problems with your assigned
item. If there was no problem then you were done. If no one had any issues it
was done in a few minutes and there was no chance for it to descend into
pointlessness or irrelevant tangets.

------
seanwilson
Agree with this! Standups are so much worse when you're remote and working
different timezones too. It's so disruptive knowing you've got to set up a
voice call at a certain time most days. It's completely against async working
and takes away your freedom to work the hours that work best for you.

------
luord
I wouldn't mind stand-ups (well, not _as much_ ) if they actually stuck to
their mission statement.

My biggest problem is that almost always someone (usually the product
owner/manager) starts droning on and on about stuff that has little to do with
daily work, usually by repeating stuff already said the day before.

------
it
I cannot upvote this enough. Why do these companies pay us all this money and
then burn it with this nonsense?

------
0027
To some extent I find standups useful for joining a team. It helps me
understand how to team operates, who the experts are, the team's struggle
points, etc. But yes, after a short while they do begin to feel mostly
pointless.

------
kthejoker2
Stand ups are the modern mashup of two great comedian quotes:

Pascal's "I have made this longer than usual because I have not had time to
make it shorter"

And Carlin's "Have you noticed that their stuff is shit and your shit is
stuff?"

------
leroman
Just a token of systemic conformism to start the morning, as a cog in the
machine..

------
keyle
The key to a good stand up is if you have nothing to add, or to say, just make
it very quick.

They're useful for people actually working together and having a sit-rep. When
it's business as usual, they just hinder morale.

------
utopkara
It is hard for one to appreciate the value of a process that helps teams
operate well in the long run, in the face of disruptions, pivots, failures,
growth, etc. If you can do without standups, good for you.

------
GoToRO
Standups (as implemented) or another way management thought they can do the
same work without hiring real developers.

You can come up with any process you want, if you don't have the people, you
have nothing.

------
EdwardDiego
Stand ups had one real value for me - maintaining my accountability to my
team.

Having to say "yesterday I was too busy arguing online so didn't do anything"
was something helpfully painful.

------
keriati1
We do standups, however the questions are more like

What task moved yesterday? (handover?) What task is going to move today?

and the most important one: What is blocked? (Who can help to unblock?)

I can recommend this format for everybody.

------
hagnat
let me start with some piece of wisdom: scrum is not a silver bullet. It may
not solve your problem, and create additional ones if done improperly.

Also, scrum is not written on stone. If something from scrum does not work for
your team/company culture, don't use it. Dont like standups ? dont have them.
Dont like poker planning ? Don't play it.

The process should help you achieve your goals easier and quicker. If the
process is hindering your work, just don't follow it.

------
mti27
Refreshing take on standups: [https://youtu.be/2u0sNRO-
QKQ?t=105](https://youtu.be/2u0sNRO-QKQ?t=105)

------
hansdieter1337
We replaced our daily standups with a chat room. Now, everyone can come in
whenever they like and the “standup” can happen totally asynchronous.

------
polkduran
We do standups so people arrive early in the morning. I was once told that
when requesting the standup to be reschedule one hour later.

------
raldi
They're even worse when the team stops standing up for them. Then they turn
into a daily agendaless mandatory half-hour meeting.

------
wreath
We started having standups are user stories instead of individuals. Reading
the article through this lense made it irrelevant.

------
sbhn
Does anybody suspect that software development is just that tad slightly a
completely micro managed profession.

------
matthewfelgate
Provocative headline. Absolute BS argument.

Daily Stand up is crucial for juniors to know what is going on.

~~~
majewsky
> _Mentoring_ is crucial for juniors to know what is going on.

FTFY

~~~
perfetti
iunno, listening to the whole team and knowing what people are working on was
wildly helpful when I was a junior. Mentoring is important but so is knowing
how the team actually tackles the problems.

Especially for juniors who are worried about seeming dumb when they have a
blocker/problem. Having that space to hear Seniors say they're stuck makes em
talk more.

I'm a consultant so I get to see all the wide wide varieties of standups and
the short sweet ones just make things hum so much nicer than a 30 minute
morning meeting.

------
josh_fyi
I'm on your side. But some, maybe most people, prefer synchronous talking. And
even with async, making a point of daily updates keeps teams focused.

~~~
ants_a
Synchronous talking has a synchronization overhead. If you do the stand-up in
the beginning of the day it forces everyone to arrive at the same time. If you
do it in the middle of the day it is an interruption for everybody. It's
usually just not worth the costs to create meetings just to satisfy the
interaction needs of extroverts in your team.

~~~
amitport
As I see it, if managed properly, daily stand-ups is more about introverts. As
one, I found the formal obligation to give verbal updates and a be in a place
to hear updates very helpful especially when I was a junior programmer.

------
rajacombinator
They’re a means of “controlling the code monkeys.” Everyone knows this.
(Except the naive devs who have bought into “agile.”)

------
wccrawford
We've been doing daily free-form standups for years. Initially, it was in-
person because nobody was working remote. Recently, one of our people moved to
another state and we decided to shift towards remote work to accommodate that,
with the eventual shift towards enabling it for everyone.

That shift has meant that all meetings now have a video component. Our weekly
meeting is everyone in a room, except the remote person who is on video. Daily
meetings are all-video, everyone participating from their desk via video chat.

Previously, our "meeting" was really a chat session that we talked about work
a little and other stuff a lot.

Now, our meeting starts with what everyone did and will be doing, working
through some issues anyone has, and then talking about whatever until we run
out of stuff to talk about, which is usually shorter than I expected, given
our previous in-person meeting length.

We have 4 developers, and this seems to be working very well for us.

Without the daily meetings, we'd not get some of these issues resolved as
quickly and we wouldn't have as much team-building time. We initially tried an
afternoon meeting for that team-building time, but it didn't work for various
people for a number of reasons.

The person writing this article seems very hostile towards the rest of the
organization. They just want to be in their little box and not have to deal
with others. They think everything can work out easily just by using Slack. I
think they're terribly mis-guided.

What I've seen instead is that people tend to try to own their problems
instead of asking for help, but daily standups give them a chance to easily
mention their issue and for others to help off-handedly. Things that people
previously held onto for days are now taking no more than a day to resolve.

I think the problem has 2 parts: Ego, and puzzles. Nobody wants to ask for
help, and they'd rather solve it themselves. And puzzles are _fun_. Most of
the great developers I've met love working through problems and figuring out a
solution, even if it's not an ideal one. The best developers also work past
these problems, but nobody is perfect, and standups definitely help.

tl;dr - Standups work for us and our team is closer for it.

------
SavageBeast
So many things to say in response to this article but lets start here: "Your
standups are killing your velocity."

Agile in general is about predictability first and measuring a predictable
velocity. Predictable velocity answers a very important question for product
management which is "When can we release".

Additionally, Agile Methodology touts Cross Functional Teams where each
developer is not a specialist in any one area of the product necessarily. The
daily standup is a good place to indicate that a dev has run into an obstacle
and seek guidance from someone else on the cross functional team who may in
fact be the in house expert on that issue.

Guidance in this case typically comes in the form of "Oh, XYZ Thing, I built
that - the code you're looking for is in /secret/stuff and if you look in
there I think you will find what you're looking for".

What guidance is not: "Im having trouble with XYZ - will someone else on the
team TOTALLY DROP THEIR SPRINT COMMITMENTS AND DO MY JOB FOR ME".

Agile and its daily standups are not about increasing velocity. They are about
ensuring predictable velocity at the cost of absolute velocity (the max the
team may be capable of performing at which itself will vary from sprint to
sprint).

Now, all that aside, the real value of the daily standup is obviously
accountability. That little 15 minute meeting forces a slacker to stand up in
front of the rest of the team and clearly indicate that they either are or are
not pulling their weight. Used properly it can be a very motivating practice.

Perhaps the author works in a place where every team member is a one person
gang capable of independently completing any task whatsoever in the bounds of
a sprint. In such an environment Agile itself does become a bottleneck. In the
prefect world Agile is absolutely unnecessary - but most of us live in a world
thats far from perfect.

In summary, Agile as a whole and certainly daily standups can and do act as a
drag on the velocity of a proficient team. However the purpose of these
practices is not to maximize velocity but rather to ensure a floor for
velocity such that a team may never achieve its maximum potential but will
instead continue to reliably deliver a velocity that is constant and
predictable. Think of this as a sort of Productivity Insurance Policy and it
makes a lot more sense.

*Additionally - I know of no law that restricts a developer from reaching out for assistance/additional guidance immediately on discovery of a blocking issue. The daily standup is just a convenient place where you have a crack at communicating with the whole team in one place. Typically with some manager type lurking quietly on the call like a parent keeping an ear on the kids playing in the other room.

~~~
modernista
_That little 15 minute meeting forces a slacker to stand up in front of the
rest of the team and clearly indicate that they either are or are not pulling
their weight._

Which again assumes -- using the article's language -- that your team is
overladen with idiot teenagers. And that management is so out of touch that it
wouldn't have any other way of sussing these people out.

------
rolltiide
What a strange rant about blockers.

Standups are supposed to take a few minutes and everyone becomes aware of what
everyone is working on or blocked by. The person that controls the gate should
become cognizant that its effecting someone else, and then it gets solved.

I love this.

I hate when standups are long winded. That removes the usefulness.

People dont need to interrupt the whole team and fish out who can help with
the blockage, it just comes up and out. Thats the point anyway.

I use logs of standups and git commits to track dev progress.

------
pandizzle
I agree @ stand-ups being useless.

I've been on both sides of them: to give information to managers and to get
information from people I delegated.

Stand-ups tend to turn into a defensive justification for 'being busy', and
distracts from the intended purpose of asking for help.

At my current job, our manager wastes more time interrupting people during
their stand-ups to tell them that they are giving the wrong amount of info
"that nobody else cares about", instead of listening or helping.

At my previous job, it was used as a way to get people in the office at a
certain time.

Your peers don't care about what you're working on, they care about sounding
busy.

~~~
sime2009
> I've been on both sides of them: to give information to managers and to get
> information from people I delegated.

This is horrific. It looks like you don't have a team which is self
regulating, autonomous and where team members support each other. You've got a
military style command and control structure where subordinates report to
their commanding officer/manager. It is everyone for themselves.

You've got far bigger problems than stand ups. There is no trust and people
are treated like children.

~~~
pandizzle
Yeah, this has been my feeling for quite a while now, so it's 'nice' to see it
being extrapolated from a situational observation.

Some individuals are trusted* while most are not trusted at all.

* Ts and Cs apply

------
paggle
I use standups to check in with everyone and... 1) inform everyone of why I'm
making certain product decisions, so that everyone gets a "feel" for the
problem space even though they're not directly talking to customers, etc. 2)
Talk about a particular problem that wouldn't get discussed as a group if
there wasn't time on the calendar every day, such as "where do we need to
improve our telemetry" and 3) to just talk to each other for 30 minutes a day.

I don't like treating engineers as bug-closing robots and I don't think they
like being treated as such. Standup gives everyone the feeling of being on a
team of people working towards a common objective.

