
Are Daily Scrum meetings worth it? - klemola
https://blog.valuemotive.com/are-daily-scrum-meetings-worth-it-6c6fb915bec4
======
kozhevnikov
Daily stand-ups have two formats, one is Round Robin that has origins in
Scrum, other is Walk the Board that is more Kanban. I highly recommend you
switching from "did yesterday/do today" to "walking the board" as it is less
about checking what each employee delivered in a day but rather what the team
can do to move tickets through the board. It is also more inclusive allowing
quiet/introverted/non-native English speaking members of the team to
participate in the meeting rather than rehearse their updates in their heads
ignoring others.

~~~
rumanator
It should be noted that the "round robin" format has an important aspect which
is to enable each team member to air his/her personal grievances regarding
anything related to the project.

~~~
moystard
I would rather have this kind of discussions in the retrospective. It is a
dedicated time for the team to discuss pain points, and to take actions to
heal them.

~~~
vasco
I think the sooner the team is aware about issues the better.

~~~
robjan
I'm going to assume the GP meant blockers rather than grievances. Grievances
are more like injustices and shouldn't really be aired at standups in a
healthy team.

------
einpoklum
This kind of daily meetings make me feel like I'm standing trial for my
crimes. Especially if I've had a bad/down/unproductive day, which happens.

Maybe it's better when you take away the power relations. And reduce the
frequency during non-critical periods.

~~~
twic
Making classic standups useful and comfortable definitely requires
psychological safety. You need to feel like you can occasionally say "worked
on X, didn't make any progress", and a manager or a rival isn't going to
pounce on you for it.

If you don't have pervasive psychological safety, there's a lot of stuff from
XP that isn't going to work.

~~~
lbriner
Exactly what I was about to say. There are many things that are dismissed in
team culture because of the fear of feeling exposed or blamed but that is an
issue of culture and/or insecurity, not a disadvantage of using agile methods.

------
dd82
For me, they are. More so in my current role with a fully remote company. All
calls are video calls, with RingCentral, Slack or Google Meet. We get to see
each other face to face, get some social time and chit-chat a few minutes
before diving into the standup.

Other teams do async standup via Slack, via Standup Alice. It seems to work
for them.

I also really like the addition of an "open forum" in my team. Is there
anything you've heard from other teams that will probably have an impact on
this sprint's tickets or ones in the queue for the next one? Its also a good
time for the PMs to relate any relevant conversations had with other PMs that
we should know about.

The real key to this is there's no power play involved, and to have a good
sense of scope about what's appropriate to bring up and what isn't. We're also
a hybrid core/product team, so regular checkins are beneficial overall.

------
seer
I think they are worth it for remote teams. Most of the work comms can be
easily done in slack, but there’s definitely a benefit of making people talk
to each other and express emotions at least once a day.

Normal offices accomplish that with water cooler talk and informal chatter,
but you miss on that with remote teams. There might be a better way to solve
the “loosing of esprit de corps” thing but dailies are the easiest thing I’ve
seen do that.

~~~
bitL
Why not weekly? Or twice a week? Advantage of remote is that you can
prioritize incoming information and everybody is onboard with asynchronous
communication by default.

~~~
seer
It's not about information sharing, dailies are crappy for that anyways. You
should always have async information centre so people can get up to speed.

The idea is to be able to share the squishy emotional human bit of working
with a team of people.

Without it I've seen people just slowly drift apart. You'd see a comment from
a coworker on your PR and be like "argh who is this guys think he is! He's
totally wrong" but if you can talk with him about it in video it becomes a lot
less confrontational. You can apologise and be apologised to.

A jira board is just a means to have some shared concern to talk about. And
done properly can leave you with a feeling of being part of something bigger,
rather than a lonely coder talking to a computer.

~~~
lowercased
> You'd see a comment from a coworker on your PR and be like "argh who is this
> guys think he is! He's totally wrong" but if you can talk with him about it
> in video it becomes a lot less confrontational. You can apologise and be
> apologised to.

Unless that doesn't happen. Perhaps he digs in his heels that he's "right"
when he's demonstrably wrong? Or 'he' is the team lead, and it doesn't matter
whether he's right or wrong, we all now move in that direction "because".
Having to have video/f2f in situations like that adds more stress.

Dealing with this situation now, and it's bad.

~~~
seer
Well one thing that "How to win friends and Influence People", "Never split
the difference" and "Non Violent Communication" in general has thought me is
that it's very hard to "convince someone you're right". Dealing with people
successfully to win them to your cause is a very hard skill to master, one
that I'm struggling with myself.

A better strategy I think is to try to get emotionally in sync with the other
person first. Win them as a friend so to speak. And visual queues in that case
become paramount. Co-location is even better, but we're talking about remote
now don't we.

People sadly don't usually listen to the facts, especially if there's an
argument, and double that if the argument is public (more than two people
involved). It requires enormous emotional courage to admit someone's right
before a lot of people, so we hardly every do it. That's what most of the
advice from those books is to get to know people first, gain their trust and
talk to their emotions rather than the facts.

Dailies are not meant to fix that I think, more like keep the team working in
the long run if it had a good start, and help leaders find out about problems
quickly and address them elsewhere.

Going off topic a bit though but in your example - a team lead that's going
off to a demonstrably wrong direction - well they have more things on their
mind than that particular thing probably, "does my team listen to me" might be
one of them or "other business consideration that we're not privy to" is
another.

One way to approach this is to support them publicly but have a one-on-one
with them and express your concerns, without personal judgement and the like.
After which you can ask them to help you with a particular task, preferably
one that you know will hit the problem where you've thought the direction
would be bad. And never say "I told you so!" Help them through the arising
situation and bam! You will have them on your side plus the project would be
moving in a good direction.

Also a lot of times it might turn out that this direction was actually
preferable. You'll get to say "yeah you were totally right" and win them to
your side as well, and learn a new thing in the process!

~~~
lowercased
> It requires enormous emotional courage to admit someone's right before a lot
> of people, so we hardly every do it.

I've got a couple of current situations where... the other person is _not
wrong_ (charitably "right"), but the timing and prioritization is poor. Or,
they may be 'right' but for wrong or bad reasoning. (yes, doing "foo" in the
code is good because is helps with code readability, but no, it doesn't bestow
another layer of security to the project, and no, it's not a 'performance
boost').

These are even harder situations to deal with, because, again, technically,
the idea being presented isn't "wrong" or "bad" in an absolute sense, just...
strategically, it a step in a demonstrably bad direction wrt to project
progression and hitting deadlines.

> or "other business consideration that we're not privy to" is another.

I've been on teams of up to 50 people - divided in to multiple smaller teams -
company in the hundreds of employees. Yes, there may be reasonings that I'm
not privy to - completely understandable (expected). I've been on teams of
3-4, talking to an end client multiple times per week about
goals/deadlines/etc. There should not be any reason for info siloing with
respect to anything at that level (save, perhaps, financial considerations
like salaries, contract amounts, etc).

------
mikece
Q. Are daily scrum meetings worth it?

Programmers: no.

Project managers: Why can't we do this twice a day?

------
sod
> Usually the better the project is going, the less you need the daily.

That quote sums it up pretty nicely. To bad of a naming for this type of
meeting. Hard to negotiate to do a "daily" less then daily.

~~~
Plyphon_
Agreed - whether it should be done daily or not is a decision based on a wide
number of inputs.

When it's work best anecdotally, is when we hold regular retrospectives ON our
agile ways of working. EG: Is the standup working for us? What should we
stop/start/continue in our standups?

When this 'retro of agile' (rather than just project/product retros) take
place regularly you quickly come across a format and cadence that works for
the team.

Tools are just tools, they should work for us, not the other way around.

------
a_ranom_dev
I'm sorry, stand ups are literally a psychological trick played by middle
managers to put pressure on devs. They undoubtably lead to higher turnover
from devs fleeing chickenshit and I've never seen one actually lead to better
code.

~~~
distantaidenn
In a past life as a Product Manager, one of my top devs rarely attended
standups. One day, she rolled into the office mid standup, went over to the
coffee machine, and prepared a cup. Never looked in our direction, and
proceeded to begin her work.

Later during our 1-1, I asked her what the issue was, and she bluntly told me
that she thought standups were useless.

I never brought it up again, as she was an amazing developer, and her
documentation was absolutely pristine. After that, I myself stopped seeing the
value in universal standups. If a person is good, they make it known in other
ways.

~~~
lbriner
That isn't the point at all. The standup isn't to make her a better developer,
it is to make the team work more effectively. What happens when someone is
taking a long time to do something that she knows a shortcut for but they
won't know because "she doesn't need to come".

It's a sad culture when a developer thinks they don't need the team or when,
for some reason, they don't have to come to standups.

~~~
mnm1
I think she said standups are useless, not that the team is useless. I
completely agree. I've never found any use for them in years of being forced
to do standups. They are 100% for managers. If someone has an issue I can help
out with, they message me directly or post in a channel and we work on it.
That's what happens. Very simple. They don't have to wait until the next day
and they don't have to bother everyone else with their likely-irrelevant
issue.

Also, how can standups be designed to make the team work more effectively?
They essentially steal some of the best development time in the day by
insisting on being the first thing done in the morning, when most people are
fresh and ready to go. There's no way in hell this was designed to be anything
but a manager's control tool designed to slow down the team in bureaucracy and
bullshit. And it does a great job at that.

~~~
sime2009
> Also, how can standups be designed to make the team work more effectively?

Tips:

* NO MANAGERS. The standup is for the scrum team to organise and help itself. It is not there give a status update for the manager. The manager isn't in the team, and people have trouble talking freely when the manager is around.

* Do an issue based standup. Discuss the status of each issue on the board from the right to left. The primary question is "What can we do to keep these issues moving along through the process?".

* At the end you can ask "Does anyone have anything else important to add?". Maybe people have to leave early today etc etc.

That's it.

------
mmsimanga
> This will interrupt programming flow.

This for me is the biggest drawback. When you are in the zone and interrupted
it takes long to get back in the flow again.

Another point is I don't solve problems in a linear fashion. When I am stuck I
sometimes jump to another part of the application that I know I will have to
tackle later on. That's just me. This is hard to explain in Agile with a
PM/scrum master present.

Edit: PM/scrum master because we have mixed environment.

~~~
twic
> This will interrupt programming flow.

This is why you do the standup first thing, before people have started
working. There is no flow to interrupt.

> Another point is I don't solve problems in a linear fashion. When I am stuck
> I sometimes jump to another part of the application that I know I will have
> to tackle later on. That's just me.

If you're doing XP, or any kanban-flavoured variety of agile, you pick up one
story/feature/etc and work on it until it's done. You might jump around in the
codebase to build that feature, but you work on one feature. That's easy and
natural to describe in a standup.

If you're not doing that, then indeed, it's going to be hard to talk about
what you've done.

But to be honest, what you're doing is almost certainly not very effective, so
maybe stop doing that?

~~~
balfirevic
> This is why you do the standup first thing, before people have started
> working. There is no flow to interrupt.

That requires all the people to come to work at the same time.

~~~
mmsimanga
This point is dealt with in the article. People have different traveling
arrangements. In my case sometimes I have to drop off my child at school and
head in after the morning rush hour. So daily stand up is not first thing in
the morning.

~~~
spzb
I worked on a project where we had the daily scrum (by conference call) at
4pm, precisely because people all started work at different times. All that
that achieved was to mean that I was unproductive from about 2pm because I was
thinking "if I get into something now I'll get interrupted before I properly
finish it"

------
ferreus
The one true benefit that i remember from my time working in scrum was when we
moved the scrum meeting from morning to 12 o`clock. And the benefit? After the
meeting, everyone was already standing, so we went straight to lunch as a
group without any further delay. Saved a lot of time and effort to organize
everyone.

------
hugg
Personally, I like the slack message standup over the meeting, but that's
mainly because I'm a terrible listener, at least with text I can go back and
see what a certain person has decided to mention. I also feel like it's easier
to mention someone that I might need help from during the day

~~~
lbriner
The problem I have with the Slack model is that it becomes opt-in. Lots of
Devs simply won't read the channels because they won't care what other people
were doing even if that knowledge helps people to skill-share, coach,
encourage or take part of the work off of someone else.

------
Yizahi
I don't like or dislike daily meetings much personally, but I think they are
needed - mainly for scrum master and PO. Daily can't be replaced realistically
with bug tracker dashboard because 80% of daily time is not bug status
discussion but let's say mostly human problems. Also I believe there is zero
correlation between success of the project as a whole and a need for daily,
none at all. People suggest async text in chat but eventually harder and more
detailed issues will raise a need to actually talk and while it will save 20
minutes time of each participant who now don't have to listen to other
people's issues it will also isolate people from potentially useful
information and prevent them to suggest their ideas or ask for clarification ,
basically limiting in-team collaboration.

~~~
mattmanser
_I think they are needed - mainly for scrum master and PO...[but] there is
zero correlation between success of the project as a whole and a need for
daily_

So, basically, what you're really saying is they're not needed and you don't
need scrum masters or POs.

~~~
Yizahi
No, I mean that when project is successful a need for daily (or other detailed
sync) doesn't diminish. You are still making decisions, plan complex features
and communicate with the same humans, only company account has more zeroes,
that's all difference.

PS: in our case SMs and POs are actually doing useful work and we aren't
holding any worthless meetings which are solely to entertain people not doing
anything. If that was what you implied.

------
jpkeisala
> Another variation would be to do the daily on Slack which can even be
> asynchronous.

That is exactly what I do. Every morning answer 3 things in Slack. It is also
good way to say "Good morning, now I start to work on X, yesterday I did Z and
I need some help on Y.

~~~
seer
The thing with dailies is not that you share your updates, its more that
you’re forced to listen to everyone else’s.

Granted you can always snooze a bit and pretend, but that kind of bad faith is
usually indicative of other deeper problems with the team.

Also this can become a drag if you’re “held accountable” rather than “helped
in need” but smart leaders would recognize that and attempt to fix the problem
in the team, and a daily like that can be a tool for them to diagnose problems
like this.

~~~
jeresuikkila
> you’re forced to listen to everyone else’s.

This seems to be an overlooked aspect here in the comments too. Yes, nobody
likes to be forced to do something but in this case it's worth it. We have
enough distractions as it is so taking 15 minutes to focus on what's important
to our colleagues can bring forth valuable connections of ideas and people.

~~~
mytailorisrich
Face to face communication, and thus listening to others, is the whole point
of the daily scrum.

------
fjfaase
As so many things with scrum, a lot depends on the attitude of the scum
master. If the scrum master is an ambitions person and focusing on results,
stand-up meetings can be become a drag. If however, the scrum master has a
focus on the team and it members, it can become a source of cooperation and
encouragement. Many companies that want to implement scrum, do not want to pay
the cost of hiring people who are good at being scrum masters (and are not
necessary software engineers), but decide to assign the role to some existing
people in the company, which, often results in people who see it is a stepping
stone to a management position to opt for the role of scrum master.

~~~
jeresuikkila
I agree with the importance of Scrum Master in the meeting but from a
different perspective. Without a dedicated Scrum Master the meetings often
feel either flat or take an off-topic life of their own. I believe that sort
of communication is also important but should then be done outside of the
Daily.

------
petetnt
I see the value in daily communication and the general topics (yesterday,
today, blockers) of the dailies, but at the same time the daily standups show
how the in general much of the modern work and communication has moved to
asynchronous methods but the text book example still requires the events to
happen in a synchronous way (eg. standup at 9 am) which obviously causes
issues.

Then you move forward to move say the dailies in Slack, at which point they
just get posted whenever people see fit, which sort of works unless the
problems themselves need to be solved synchronously, as it is with many cases
and they easily just end up being status reports instead of actual planning.

------
mcv
I think they're absolutely worth it. The interruption of flow is minor,
because they're predictable. You can plan around them. If you're working on
something really complex and urgent, I don't mind if you skip it occasionally
(but don't make that a habit).

I think it's good to start the day together, with some idea of what everybody
is working on. It helps to detect some issues that otherwise might be ignored
or detected too late. Generally, communication is good, and short
communication is better.

~~~
lbriner
Yeah, nothing worse than finding out that someone has implemented something
that you've already done somewhere else because you didn't know it was being
worked on.

Short is definitely good as is the chance to chip in a bit of unsolicited
advice from one dev to another ;-)

------
athenot
I haven't found a way to make daily standups work in my team which is fully
remote and spread out on 3 continents and 4 time zones (so there is no "start
of day"). Instead I have a weekly sync with everyone and 1:1 with each person
on a weekly basis.

Kanban board gets reviewed weekly for assignment and direction (and I keep an
eye on it thoughout the week). Blockers get addressed asynchronously in
dedicated discussion spaces as soon as they arise. If a solution isn't found
in chat then it becomes a topic on the sync meeting. But generally, there's no
"spinning wheels" as everyone is mature and doesn't need a short leash.

Which leads me to trust. Everyone in our team has a decent amount of
experience. They all know when they are stuck and they all know where to ask
for help. I've always felt that trust is empowering and that's what I wish for
everyone on my team.

But in this context, 1:1 are very important and I try my best to make them
safe spaces for people to bring up issues which would be more uncomfortable to
bring up in a group setting, especially for introvert personalities.

Ideally, pick what works best for YOUR team. Experiment and try new things.
What works today may not be the right thing in a year. These are tools, not
dogmas. The worst process is the one everyone follows but nobody knows why nor
how/if it helps.

------
valcker
Yes, they do but it depends on the context. In my previous company (web
agency) they were solving several issues at the same time:

\- Project Manager (Proxy Product Owner) is communicating with the client on a
daily basis and is getting some important updates about the progress of the
Sprint;

\- if there are some unexpected developments (for example, some User Stories
appeared to be more complex) the Team and the PO can make a decision about it
together, discuss various options, etc;

\- the distributed team has a chance to see each other (we were encouraging
video calls via Google Meet).

However, there are some certain rules which should be followed in order to
make Daily Scrums effective:

\- video (or at least audio) conferences for distributed teams – it can
actually be slower to have this meeting via Slack;

\- they must be timeboxed (15 minutes max);

\- stay pragmatic about what you are discussing and ask the feedback of your
team about it.

------
JohnFen
In my experience, daily scrums are without value. A well-functioning team
already knows what everyone else is working on, what problems they're having,
and etc.

If a team isn't well-functioning, then daily scrums could have some value --
but I think a better approach would be to fix the team.

------
balfirevic
When I was put in charge of a new team for a new project at my previous
company, we did the most agile thing there is. We got together and asked
ourselves (all of us having previously been on teams that had daily standups):
"So, what do you all think, is the daily standup worth it? No? Alright, let's
try without it."

It worked great. We ended up doing a quick meetings 1-2 times a week to sync-
up and get the idea of where we are. Any blockers would be brought up
informally (through Slack or in-person). We all knew each other well, so trust
was high to begin with. Also, it was a relatively small team of 5 people.

I guess the point is that "having daily standups" is not agile. Regularly
asking yourselves if they are or would be useful (whatever the answer may be)
is.

------
pszndr
Every article:

Title: Is [x] better than [y]?

Article: Depends on context

~~~
THrau
Well, isn't this how the world works? If yes, then x. If not, then y. I'm
happy to live in a non-binary world.

------
nakodari
For a small remote company like ours, it would be exhausting to do daily scrum
meetings. Instead, we have an hour-long weekly scrum meeting on Monday and
it's more effective.

~~~
ljf
Can you give a little more context about why it would become exhausting for
remote workers? I'd seen terrible stand ups and good ones, but the location of
those taking part has rarely been a deciding factor.

~~~
nakodari
It is a waste of time. Whatever you need to discuss regarding the tasks can be
discussed once a week and then once the tasks have been assigned and
discussed, trust the team to work at their own pace and time and deliver it by
next Monday instead of micromanaging the team every day.

~~~
ljf
But why is that especially exhausting for remote workers? Why not local ones
too?

You also foucs on assigned tasks rather than a team working together to get
stuff done. Sounds like Software engineers, not product engineers. If you are
pre assigning tasks and working separately then yes a daily scrum has no
value.

But that isn't the point of a daily scrum, or scrum/agile at all. The focus
needs to be on getting value to a customer together as fast as possible - not
individuals doing a task each to build to a pre-defined whole. Iteration not
increments.

------
agigao
NO.

~~~
kierenj
Because?

------
_tkzm
i loved the dailies. it was the best way to earn money without doing any work.
i always tried to prolong the meetings as much as possible. ah, i miss those
days.

------
tarique313
No

