

Are stand-ups (meetings) getting mainstream?  - louhong
http://online.wsj.com/article/SB10001424052970204652904577193460472598378.html?mod=WSJ_hp_mostpop_read

======
famousactress
The first couple of times I was in a group that implemented daily standups, I
was encouraged.. Seemed like it might increase operational awareness in a
lightweight way. I was wrong. I think they're stupid.

The day-boundary is arbitrary. It encourages someone who gets stuck on
something at 2pm to spend the rest of the day banging on it and bring it up
tomorrow. Or, in better functioning teams, we deal with it at 2pm and the
standups become irrelevant. That was what I found.. is that as a team lead I
knew what everyone was doing before we met in the morning. Another popular
tendency is to pull in PM, or maybe my boss.. but then I get to waste 6
people's time trying to communicate what's happening to them on a still-
arbitrary schedule.

~~~
jbrechtel
Arbitrary schedule and bad habits about wasting time on stupid problems aside,
I'd agree that a standup for a well functioning, co-located dev team is
largely going to be redundant.

The most value I've found in standups are when you have a cross functional
team that can communicate status on different things to everyone all at once.
BAs, QAs, devs, IM/PM, and product owners aren't all going to stay up to date
with each other naturally on most teams.

Of course, if teams are working in very long iterations with out-of-cycle QA
then each functional aspect of the team staying up to date with each other on
a daily basis yields less value. Such a setup tends to bring about other
problems in many scenarios though.

In the end it's all about context. To say a daily standup is a stupid practice
without context (implying in any context) is a bit too broad of a statement
IMHO.

~~~
famousactress
Thing is:

1\. In general, I'd like to receive information asynchronously. Meetings
should be for solving problems. They're a team-mutex, and mutexes should be
avoided.

2\. Standups are generally by definition, not for solving problems.

~~~
jbrechtel
Standups are good for both surfacing as well as identifying problems (e.g.
things that don't appear to be problems).

Standups aside, sure, ssync information is good. However, it's not nearly as
rich as face to face communication.

I'm not sure why you say meetings should be for solving problems. The majority
of my meetings are about sharing information and planning. I solve problems at
my desk.

------
dhx
Why interrupt what people are doing to organise a "meeting" that consists
entirely of content that is much better read directly from a collaborative
project management/issue tracking tool?

A meeting may only be 10 minutes long but the loss of productivity is likely
going to be significantly higher. Employees will need to page out[1][2] what
they've been working on -- a very expensive process.

Managers should be ensuring that employees have quick and easy access to
information of relevance on demand, rather than on an arbitrary time scale.
Issue tracking software (web based for simplicity) allows teams to view and
contribute to the big picture at a time that works best for each employee.
These systems require full time staff to actively maintain them. Typical
duties could include sorting and filtering information (via way of updating
fields on an issue), creating links between issues to aid planning and
discoverability, correcting mistakes, ensuring consistency and monitoring
usage to implement improvements (particularly simplifying and automating the
system).

This isn't a disguised plea for ISO 9001 Quality Management Systems because it
focuses on the users (employees) getting their work done -- not rigid and
inflexible processes for the sake of standards compliance. Most quality
management approaches I've come across fail because they are burdensome to
getting real work done. They're not user friendly. They're typically rigid and
deterministic in design where the actual work is flexible and probabilistic.
Users are left wondering how their use of the system actually helps the
project -- there is no clear link. Tedious manual work is required where an
automated approach could be implemented. The systems become too complex for
anyone to comprehend. Coming back to the paging[1][2] analogy, users run out
of working memory before they get a chance to input or retrieve data to/from
the system -- it's all wasted on deciding[3] which button from 50 needs to be
pressed.

Human interaction factors and cognitive science are crucial to this
discussion. It is disappointing to read that many companies are blindly
accepting stand-up meetings as common practice without consideration to the
well established science behind organisational communication/teamwork.

[1] <http://news.ycombinator.com/item?id=97953> [2]
<https://en.wikipedia.org/wiki/Working_memory> [3]
<https://en.wikipedia.org/wiki/Decision_fatigue>

------
Gman32
After a few weeks of daily meetings, even brief ones, the quality of
information being communicated really decreases.

I've had better results where: A) frequency of team meetings increases as
deadlines get closer, going from once per week to 2x per day if needed. B)
every day managers spend 5-10 minutes of 1-on-1 time with each team member
actually inspecting their work.

------
X-Istence
The startup I currently work for uses stand-up scrum's in the morning to
discuss what one has crushed the day before (completed items) and what one is
going to crush today. This is also the time to explain to the various
different teams (Android/Java API, C++ api, server/backend) what you changed,
what things they need you to be aware of and what requires more meetings and
or having a time where a switch-over is required do to changing something that
touches all teams or some of the teams. For example, letting the other teams
know that DNS entries now server ULA IPv6 addresses as well as IPv4 addresses
and they should probably do testing to verify everything still functions.

It works for us, although sometimes the meetings can be a drag when the day
before you spent a lot of time in meetings and you don't have a lot of input.
It is one way of kinda putting you on the spot if you aren't producing
anything which keeps people accountable.

------
WestCoastJustin
The idea of stand-ups seems to stem from agile and development houses, but we
network/unix admins have daily stand-up meetings with developers/operations
too. We chat about what we did last 24, and what we want to do next 24, and if
there are any issues we need help with. Helps to iron out any road blocks. I
was really hesitant as first, and I think the group as a whole looked down on
the idea, but it had really turned things around, and we are working much
better as a team. Occasionally we go off on tangents, but it's nice to know
what people are working on, and keeps people from slacking off when you're
waiting for something.

------
dchmiel
Do any larger companies (Google, Apple, etc) implement stand-ups? I'm curious
to know if this is being adopted by companies with larger staff numbers.

~~~
xxpor
Most teams that I know of at Amazon do. The 2 teams I have been on aren't so
strict about the whole "you MUST stand up" part though.

~~~
InclinedPlane
While I was working at a completely unrelated company that started off as a
book store and turned into a global online retailer and PaaS provider there
was a period of several months when my team was doing standups every day of
around a dozen people (devs, test, mgmt) which tended to last anywhere from
half an hour to an hour and a half.

------
paulhauggis
If I worked for a company that forced me to go to "stand-ups", I probably
wouldn't contribute much to the meeting. As it is, I hate these sorts of
meetings.

This just makes it worse.

------
strandev
It's a "brute force" way to get people to communicate on a team.

