
Daily Meetings Are Great but You Should Never Have Them - jimrhoskins
http://wellbredgrapefruit.com/blog/2013/05/28/daily-meetings-are-great-but-you-should-never-have-them/
======
onemorepassword
Part 32904 in the continuing saga of _"my stand-ups suck, so all stand-ups
suck"_.

Sorry, not even going to bother with non-snark response. I did that the 32903
times before, and someone else already took the bait.

But I'll bite on this though:

> _All meetings are terrible._

Meetings can be awesome. I've been to meetings full of great new ideas. I've
been in meetings that saved companies. I've been in meetings in which shit was
actually decided _and_ followed up on!

I've been in meetings that lasted for days(!) but eliminated months of painful
processes and left people feeling exhausted but victorious.

Meetings can be great. Meetings can be fun. Meetings can have a purpose.
Meetings can have results. Meetings can change the world.

It's badly organized, forced and unproductive meetings with the wrong people
that suck. Guess what, that applies to virtually any activity with a group of
people. Including orgies. Especially orgies.

~~~
derefr
I think there's a No True Scotsman effect at work here: "meeting" is the
general abstract superclass used to refer to "people talking at a table."
However, "meeting" has some very useful subclasses--for example, _debate_ and
_negotiation_. Real things get done in _debates_ and _negotiations_. But
people don't think of those at "meetings", per se, so "meeting" gets stuck
with all the negative connotations and none of the positive ones. (In est, a
useful meeting is not a True Meeting; it's something else.)

------
DanielBMarkham
Ok, I'll take the bait.

I need to make a web page about standups and just start posting links to it.
It's the same question time after time, and I keep thinking I'm going to
forget part of the answer.

Standups are not meetings, at least not like I know them. Some teams have
"standups" while doing a morning walk. Some meet at the coffee shop. Some have
stopwatches and pigs and chickens and all sorts of other things. So what?
Meetings usually involve sitting around, an agenda, a leader, a desired set of
outcomes, and so forth. Standups really don't have any of that in the
traditional sense. The output from a standup is just an informal agenda for
the day. People meet, they discuss what's up, they break up and informally get
together to do stuff. Standups are designed to _prevent_ meetings, not be
another one.

"Because it’s the information that’s great: the meetings are time-sinks."

No, it's about non-verbal communication and social interaction around common
team problems. We've found that listing the 3 things helps do that. You might
get the same effect with having each person act out an improv based on their
feelings. I don't know. Give it a shot. But it's not about information. No.
No. No, no no. Technology teams are made of people, not robots, and the work
of everybody getting on the same page and keeping up is a _human_ job full of
social nuance, not the exchange of status information.

Later on we get here:

"...the only benefit to having a meeting is the face-to-face discussion that
it allows for. Or, to put it another way: if you’re structuring your meeting
around trying to eliminate anything that isn’t a two-minute “this is what I
did/am doing/am having trouble with” update, why are you having a meeting at
all?"

"Discussion" a much better word, but you're once again assuming that it's all
some kind of information flow happening. _The hardest part of working in
technology teams is the social factor_ , not the bandwidth of information
flow. Standups are about physically looking each other in the eye, figuring
out where everybody is, and figuring out if you can help. It's not
information, and it's really not discussion.

I'll put in a plug for anybody that's interested: I've created a no-frills
"Agile Team Tune-up" email course. No selling, just a weekly concept explained
with ways to apply in your team. If you're interested, here's the sign-up:
<http://bit.ly/15sz0Pl>

~~~
Spearchucker
Unfortunately these daily meetings hardly ever work out that way -

 _In Scrum, for example, a daily project team meeting occurs. It’s called a
daily scrum, or stand-up. The stand-up has guidelines, including limiting the
meeting length to 15 minutes. My experience is that this never occurs – stand-
ups usually run on for at least half an hour, during which I’m subjected to
anecdotes, show-offs, excuses and, if I’m really unlucky, insinuations and
blame. The worst stand-ups include managers – their presence turns any self-
respecting stand-up into a status report._

Ref.
[http://www.wittenburg.co.uk/Entry.aspx?id=dce9dde8-d770-47c2...](http://www.wittenburg.co.uk/Entry.aspx?id=dce9dde8-d770-47c2-ad66-937cfabadb59)

~~~
stephengillie
You make an excellent point. Meetings are basically "team work breaks", where
everyone gets to stop working but must remain together. Usually, team members
discuss work, as that's always something these people have in common.

I'm contrasting this with the typical work break, where the team breaks into
individuals for 10-15 minutes and everyone goes to a different location (water
cooler, phone, bathroom, outdoors to smoke or stretch or walk).

------
wpietri
This article is like magic! By which I mean the exciting part is all
misdirection.

In meetings, the time lost is obvious. Which is why people focus on doing them
well. By moving it to email, you're not saving time; you're just hiding it.
And, I'm sure, increasing it.

I'm a fast writer. I practice pretty much every day. But there is no way I
could write my standup contributions as quickly as just saying them. I'd guess
writing is 5-10x as long. In a stand-up, I can point at the board and say,
"I'm done with this; it was easy. I'm still working on that; it got hairy." If
somebody needs more, I can see it on their face and raise an eyebrow; they'll
ask me what they need to know.

To write a decent status update, I have to guess at all the reasonable
questions and head most of them off. It is much more work. And then to keep
up, I have to check my email. And integrate each person's comments with
everybody else's to try to form a coherent picture. And then to follow up on
the mysterious bits. A giant waste. I try to keep email off my coding machines
entirely; distraction is a productivity-killer.

This also ignores so much of what I get out of stand-ups. I can see who's
happy and who's dragging. I get an easy opportunity to grab somebody for a
quick discussion. I get information through tone of voice, posture, and
expression. Information about relationships, about features, about code. I get
charged up at the beginning of the day knowing that we are all diving in on
the same thing.

~~~
mindcrime
_To write a decent status update, I have to guess at all the reasonable
questions and head most of them off. It is much more work_

I think the assumption here is that there is a very limited set of basic
questions that apply to everybody and that become the default. For example:
"What did you work on yesterday?" "What are you working on today?" "Do you
have any blockers or concerns?" If you just got everybody to submit those
three questions and their answers, it would go a long way.

~~~
wpietri
Sure, and I am saying it takes a lot more work to write that up well than to
have a conversation.

I guess it could be that people were answering those things in an entirely
dull way. In which case, no wonder the meeting was seen as worthless. I'd
suggest putting the boring information in a shared artifact. Personally, I
tend to use as physical board. I also see virtual teams using a virtual board
(like Trello) for that.

The value of the stand-up is in what people say that goes beyond the obvious.

~~~
mindcrime
_The value of the stand-up is in what people say that goes beyond the
obvious._

I agree. I just don't necessarily think that you need that level of
interaction for a status meeting _every day_. OK, maybe some teams do.. and I
can see why some people might prefer it. But my experience has been that it's
overkill.

That said, different teams, different cultures, different situations, could
definitely dictate different approaches.

My biggest gripe with the daily meetings is that they force a context switch
that somehow seems to always come at the most awkward possible time, no matter
when you schedule the meeting. Requiring lots of face-to-face meetings also
runs counter to the idea of having distributed teams and a lot of "work
remotely" flexibility, which I also tend to favor.

But, again, YMMV.

~~~
wpietri
Yeah, I could imagine contexts where not much is going on, or where the work
is pretty routine, or where collaboration is low. In which case, no need to
talk frequently.

I usually work in exploratory, high-volatility contexts, where there's plenty
to talk about. I also favor continuous deployment; I think the last shop
averaged about a release per engineer per day.

Given that very exploratory context, I also really like people generally being
present. If that's the default, you can iterate much more quickly.

~~~
mindcrime
People can talking without having a daily, scheduled, standup meeting! If the
only time people are talking is during the standup, I would consider that an
anti-pattern. :-)

I'm certainly not advocating _not_ communicating or collaborating, and
frequently. Just saying that the daily standup isn't always required.

 _Given that very exploratory context, I also really like people generally
being present. If that's the default, you can iterate much more quickly._

Fair enough.

------
swanson
Of the Three Pillars of Standup (what you did yesterday[1], what you are doing
today[2], what are you stuck on[3]) I really only find [3] to be of much
value.

Git log/Kanban board can tell you [1]/[2] if you actually need to know these
things (hint: you probably don't unless you are manager/team lead/product
owner).

Kanban blocker stickies can do [3] but I think a designated "safe haven" to
get help is useful, at least for teams of varying skill level and comfort with
one another.

My favorite standups have been the ones that "devolved" (in the formal
capital-A Agile sense) to "Anyone blocked?" ___crickets_ __"Okay. Good
standup."

~~~
DanielBMarkham
You know, you have an excellent point. If you wanted to tweak standups, how
about just doing #3? Everybody say where you're blocked and how we can help.
Boom. Standup over.

It'd be fun to try.

~~~
swanson
Yep - a team near my desk routinely has sub-30 second standups following that
format. I am probably a bit sour on standups in general since my last project
had 10+ person, 15+ minute meetings (sometimes with the client present...)
that added very little value for their cost ($1XX x 0.25 x 12).

~~~
DanielBMarkham
Team size kills so many things. I had a client once that couldn't start a
project without at least 15 people. Those projects were doomed from the start.

Maybe I'm getting old and cranky, but lately 7 is becoming my limit for people
on a team, with team size as low as 3 looking pretty damned good.

------
timfrietas
This has it's own set of problems, namely, it is more difficult to do this
over email than it is to just talk face-to-face; that is, it is slower.

Yes, what the author offers here is asynchronous and most developers love that
idea. However, in practice I've seen this method fail more often than it
succeeds. Why?

Face-to-face synchronous communication matters. Problems are addressed
quickly, brainstorms happen. Personal relationships develop; mentors and
mentee relationships evolve. Perhaps another developer had your problem with
some pesky JS library last week and gives you just the clue you needed, and so
on. I actually think standup meetings are not only not the worst thing ever,
but the best thing ever for a growing developer as they allow them to quickly
see what others are doing, and quickly get feedback on their own work.

------
Kiro
We have these kind of daily meetings and I would never replace them with an
email thread. Answering the three questions in writing would not only be more
burdensome but you would also lose out on the valuable instant feedback.

------
Deestan
What I dislike about this is how preoccupied people are with _how_ the rules
of daily meetings should be enforced. As if it is a given that a) there must
be daily meetings, and b) they must be _defined as rules_. I would rather we
focused on the goal instead: The dev team must be coordinated, and they must
not deviate enormously from the schedule without the project manager at least
knowing about it.

So here's our process for ensuring this:

Nothing.

It turns out that when you have skilled and motivated people working without
process handcuffs, they are able, and actually eager to _self-organize_.

\- How do we keep in touch? We set up a HipChat room where we discuss things
both on and off topic asynchronously. Is our process "we will use a chat room
for daily chitchat"? No. We use it because it makes sense, and when it stops
making sense, we do something else instead.

\- How do we catch one dev needing help? He says so. Then we can meet up and
pair program or discuss the issue or whatever makes sense. Do we have "pair
programming tuesdays" to enforce this? No. It just happens when it needs to.

\- How do we make sure one dev doesn't drift off procastinating for two weeks?
Turns out that's not really a relevant problem for us. We find that skilled
devs given freedom and responsibility will live up to it. But on the off
chance that it happened, we _would_ notice the lack of work flowing from
checkins and code review and work tasks.

\- How do we make sure the project manager knows of any problems? We tell him.
Simple as that. And usually on the way to luch, he asks "things going ok?" and
we answer "yep" or "slightly behind it seems, we might delay task X till next
week". Do we have a "pre lunch meetup" process to define this? No. It happens
naturally because _we all have a desire to cooperate_.

\- How do we make sure the devs don't shit in the sink while on the bathroom?
We _could_ have a process in place with a post-bowel-movement checkup rota. Or
we could enforce pair toiletgoing with a senior architect. But we decided not
to. It turns out the devs have a sense of hygiene, and therefore shit into the
toilet bowl of their own accord.

~~~
wpietri
Well, as long as there are observable regularities in your work, you have a
process, just not a formal process. As long as there is a way for people to do
things and get called out or admonished for it, you have norms, just not
explicit rules.

What you're talking about is, at least in the Agile world, described with the
shu-ha-ri model. People at the "shu" level really want rules so they know what
to do. People at the "ha" level want rules for others. It's only at the "ri"
level, that of mastery, that you can fluidly do what works without discussion.

Getting a team to self-organization is tricky. Sometimes rules help.

For example, I know one team that really loved their daily stand-up, but they
had a problem with chronic lateness wasting a lot of time. So for a while they
created a rule that lateness was punished by $1/minute into the beer jar. I
once saw the CEO put $45 in. He was pretty pissed, but he was on time after
that. Eventually, everybody got their shit together and they didn't need the
rule anymore.

~~~
Deestan
> Getting a team to self-organization is tricky. Sometimes rules help.

Absolutely true. I actually feel bad for not emphasizing that properly. Teams
of self-organizing people aren't as common as it should be.

My point is that we should not add rules unless we _really_ need to, and that
people are more likely to self-organize if given freedom.

E.g. If we turned out to have actual persistent problems communicating to the
project manager, we would introduce rules.

------
mindcrime
I'm sort of onboard with this and sort of not. I certainly believe that actual
face-to-face communication has a place, and that it should occur with some
regular frequency. I also believe in short, fast, lightweight meetings ala
what a daily Scrum meeting _should_ be.

But, between the fact that a lot of these meetings devolve into something that
is not short, fast or lightweight, and my observation over the years that
_daily_ is probably overly frequent for these meetings, I tend to mostly agree
with the author of TFA.

Every team has it's unique needs, but for a lot of teams I'd go for a
compromise with one, maybe two meatspace meetings per week (maybe Monday and
Thursday) and then a technical solution using email or blogs or an enterprise
social network or whatever, for a daily "standup".

It's not just "scrum" type meetings that could be replaced with a "no physical
presence required" techie solution either... some companies have a culture of
accountability (which is a good thing) taken to an extreme degree where half
the company spends most of their time tied up in "status update" and
"checkpoint" meetings. I've talked to people who say they can never schedule a
real meeting (that is, a one off for attacking a specific problem) in their
companies, because all of the participants are too over-committed with these
status meetings! For these, I absolutely advocate finding a way to communicate
most of thi status information electronically, and cut the frequency (and
length) of the meatspace meetings back dramatically.

------
btilly
There are other costs to daily meetings - namely when should you have them? If
you have them in the middle of the day, you interrupt the schedule. At the end
of the day, then the energy you're looking to develop in the meeting goes the
wrong direction (plus it inevitably interrupts someone who was in flow and
just wanted to keep working). Therefore you want it at the beginning of the
day.

But what if people want to start their days at different times? Now they
can't!

I feel this a lot right now. Due to unexpected personal circumstances I have
wound up needing to go from "provide child support" to "provide financial
support". So I just began a job search. But one past employer who would be
otherwise reasonable to apply to went onto my list of places to avoid applying
to for a while. Why? Because most of their teams have daily standups at around
9:30-10 AM, and there is still rush hour traffic around Los Angeles at that
time. I'd like to spend the morning with my kids, get ready, arrive at 11 AM
and totally miss rush hour. (Then leave late and miss it on the other end as
well!) But they can't accommodate that.

If you have daily meetings, have you discouraged someone from working for you?
Quite possibly so. But if my experience is a guide, you probably won't even
hear about it.

------
dwc
From the title I was expecting to disagree, but this isn't about "not having"
the meetings, it's about taking them offline. I think I agree with this. I
should have done this at my previous job. The devs had flexible schedules
(which I support), and trying to have a fixed schedule for daily stand-ups was
unworkable and I eventually gave up. This would have worked much better.

------
Bognar
I used to work as a process engineer at a semiconductor manufacturing plant.
The plant ran 24/7, so we had (almost) round-the-clock engineering coverage.
"Stand-up" meetings weren't viable because many of the engineers on the same
team would work at different hours, so at the end of the day each engineer was
required to send a "passdown" via e-mail.

A passdown included the experiments that ran on your reactor for the day, the
experiments that were planned for the next day, and potential research
directions based on the results. With a trail of passdowns, any engineer could
easily pick up on the thread of logic from the previous engineer and continue
working in their stead (if they are on their weekend, vacation, sick, etc.).

The nature of the job necessitated leaving behind a trail for someone else to
follow, but I think it's a great process to be adapted to other work
environments.

------
codex
Daily meetings are not really for obtaining useful status information. They're
about habituating people into doing real work every day, so that they don't
feel like jackasses when they have to report to their peers that they didn't
do anything yesterday.

People ostensibly do work to get paid, but that's not really what motivates
them to get anything done. Fear of losing face is one such motivation. The
dollar is the currency of this century, but social currency is millions of
years old and works much better.

And that is why these meetings must be face to face; email doesn't generate
enough shame.

------
beat
Meetings are synchronous, email is asynchronous. The feedback loop is tighter.

Standups get lots of bright minds in the same place at the same time.

Standups let you know what else is going on, which is indeed useful. I've
never understood this thing about silos and belittling out-of-band
communication. The only way to get the Big Picture is to hear what other
people are working on, preferably in an unfiltered manner. Then again, a lot
of developers seem to prefer their little heads-down silo, worrying that their
little room is uncomfortably warm without knowing the house is on fire.

------
atte
My team uses IFTTT for daily standup emails, and it's really been a huge help
for us. Here's the recipe if anyone else wants to use it:
<https://ifttt.com/recipes/86294>

------
etler
I swear I see a variant of this article every week, and the discussion is
always the same. TL;DR make sure your standup meetings are incredibly fast.

------
VeejayRampay
I've yet to participate in a useful meeting.

