
Standups are Not Poisonous - dshimy
http://dshimy.github.com/blog/2013/03/30/standups-are-not-poisonous/
======
onemorepassword
Standups can however very easily become very uncomfortable in a dysfunctional
environment. (As the original article unwittingly demonstrated.)

Consider the standup to be the canary in the coalmine. Most of the time people
can ignore the dysfunction, work around it and pretend it isn't happening by
just getting on with the job as much as possible.

But the standup will then become increasingly uncomfortable. _Every single
day._

In a healthy organisation, you can have perfectly pleasant standups, even
without Scrum or Agile. I mean, what does a healthy team have to fear from
standing around for a few minutes bringing each other up to speed?

It's a process that is very close to what often happens quite naturally around
the time everyone on the team has arrived at the office (or online).

A standup can only become poisonous if the poison is injected from elsewhere.
In Gareth's case abusing it for management status reports. In other cases it
might be tension between team members, not having a clear goal, whatever.

The point is, you cannot have pleasant standup if there is that kind of stuff
going on. Which is all the more reason to have a standup, unless it's your
policy to ignore problems rather than dealing with them.

Standups aren't just _not_ poisonous either: they are a very good poison
detector.

~~~
hobs
It's a process that is very close to what often happens quite naturally around
the time everyone on the team has arrived at the office (or online).

This is exactly the behavior I have seen of well functioning teams. Usually
there is a period when the person comes in, maybe after coming up to speed on
their email where they get informed and up to speed on what is happening with
everyone, if anyone needs anything, what people are working on, and then get
to work!

Standups are just a formalized approach to what can be a drawn out process for
an individual, and in some cases may not be "normal" for your standard
introvert dev types who sit at a computer all day and perceive meetings as
multi-hour long chores that are inflicted on their participants instead of
quick high quality bursts of information distributed in an efficient fashion
(face to face).

------
drewmclellan
I used to hate standups when I was at Yahoo. Maybe it's more a sign of how
broken Yahoo is than how broken standups are, but the daily process was
roughly:

0\. 9am, catch up on email, then coast for a while knowing you'll have to stop
work at 10am.

1\. Find out which meeting room the 10am standup is in

2\. Figure out where in the building that room is

3\. Travel to the rough part of the building, hunt around for the room.

4\. Wait for everyone else to do the same.

It's now 10.20am

5\. Stand (OMG the standing!) around for 30 minutes listening to a boring load
of status updates from 20 people that have absolutely nothing to do with you.

6\. Give your status update (Yesterday I did some work. Today I'll do some
more work. What's blocking me is this f'king meeting.)

It's now 10.50am

7\. Travel back to the part of the building your desk is in today (if you can
find it) and grab a coffee on the way.

That's an hour gone, and it's only another hour to lunch, so no point getting
into anything too major. Knock off some smaller to-do items. Lunchtime!

An alien race observing us would conclude that teams were a device used to
prevent work getting done.

~~~
wpietri
Wow, that's like a zoo of process pathologies. In order, the things I see:

I like doing the stand-up as early as possible, so that there's minimal slack
time before hand. And I prefer to work in ways that are less dependent on the
state in one's head, including test-driven development and pair programming.

The standup is always in the team room. Everybody on the same team works in
the same room. Generally, you do it in front of the kanban that shows the
state of the project.

Because it's right where everybody works, it's pretty easy to be on time.
Regardless, it starts on time. No waiting for stragglers; it just encourages
them.

You stand for 10 minutes or so.

The team is some reasonable size; I think of 12 as a maximum.

If the people turning up have nothing to do with you, then it's not actually a
team. Teams are groups of people that win or lose together. Team members help
one another out to achieve shared goals.

If what people say is boring, you should be able to tell them so. They are
there to talk to the team; there's no point in them saying things that aren't
useful to the team.

Coffee should be in or near the team room. Ditto water, snacks, and other
things necessary for humans to do work.

The stand-up should be run in such a way that people leave ready to jump on
things.

If I had to guess from your description, I'd say that Yahoo took a top-down
culture, pasted on some Agile rituals, and kept right doing the same old
bullshit. Which, honestly, is a giant waste of time. If you're going to do
waterfall in a command-and-control context, just do that. No sense putting
agile lipstick on your waterfall pig.

------
phamilton
"Remember, they are not status meetings."

Additionally, I think it is important to remember that standup is not a
"justify my existence on the team" meeting. Having nothing to report is fine.

~~~
skrebbel
I agree, but i notice that i find it difficult to act on it, and many with me.
Any tips for how to get the "look, i did work" urge out of the way?

~~~
wpietri
To me, that's a sign of low collaboration and low trust. If your team does
regular retrospectives, I'd just say, "Look, I feel like in stand-ups, I keep
having to justify my existence. Do other people feel that? What can we change
to make that better?"

Off the top of my head, I'd look at the size of the unit of work and the
length of the release cycle. I think Agile processes work best when the work
is broken down into lots of small deliverables that meet the INVEST criteria:

<http://en.wikipedia.org/wiki/INVEST_%28mnemonic%29>

If the team is jointly completing a few shippable things a day, then everybody
should have a pretty good idea that everybody else is working. Doubly so if
those are actually getting released daily.

------
projectileboy
Honestly, I can't understand all of the vitriol around "agile" methods that
arises here occasionally. If you're doing something that works for your team,
do it, if it doesn't work, do something else. Isn't that the whole idea behind
"agile" stuff? Do people get stuck in situations where they have to do X
because "we're doing agile, and agile says we must do X"? If so, can't the
offenders be gently pointed to <http://agilemanifesto.org> ?

~~~
brazzy
I believe ist's a combination of never having experienced the monstrosities
agile was invented to replace, having experienced agile done wrong, and
natural cowboy coder hybris.

~~~
paulrademacher
In my experience, the "cowboy coder" is sometimes indeed disruptive (large
unannounced refactors, e.g.), but almost always they are the most productive
people on the team, the ones who contribute the best and most code.

------
jlarocco
IMO the usefulness of standup meetings depends entirely on the project and the
team. It's impossible to categorically say they're good or bad.

For a while I worked on a team with a small codebase, which we all knew pretty
well, and it was very likely that if somebody made a change today, I'd be
working in the same area of code in the next day or two.

In that situation I thought standups were really helpful.

My current team/project is a bit larger and it's maintenance on a much, much
larger code base. The project is large enough that nobody really knows the
whole thing very well, and everybody works on a different section and there's
not much overlap. If I were to switch places with somebody I'd have a lot more
to learn than just what they've worked on recently.

On this project we're still required to do standups, but they're useless. The
information wouldn't be very useful to me even if people kept to one or two
sentences of what they were doing. Of course, few people do that, and they
usually go into obscure details that maybe two people in the whole group
really understand. And that's when I tune out...

------
stevenp
At my current job at turntable.fm, we only have standups twice a week (Tuesday
and Thursday), and I honestly was surprised at how effective that is. I've
always operated under the assumption that a standup needs to happen daily to
be valuable, but trying them 2x weekly has changed my mind.

I think the real problem is when a standup is the only way that a team
actually communicates status. At turntable we rely heavily on chat, which also
contains messages indicating when new things are being pushed, and we also
make it a point to have a lot of face-to-face communication. Our twice-weekly
standups are a good way to fill in the gaps, if there are any, but they are by
no means the only way that people find out what's going on.

~~~
vpeters25
And this is a very good example on what Agile is about. The daily stand ups
are part of the basic "framework" but not mandatory if something else works
better for a team. The key is to constantly inspect how the process is working
and be open, as a team, to make adjustments.

------
moron4hire
I have tried to get this point across at every place I have worked. Management
covets micromanagement, so stands turn into status meetings.

~~~
kamkazemoose
My team just went through more agile training, and one piece of advice I found
interesting was to consider keeping the managers out of the standup if it's
not working. The meeting is to help others on the team, so that's the only
people who need to be there.

~~~
wpietri
Absolutely! And once things are running well enough that you can let the
managers back in, it's still reasonable to forbid them to talk. Unless they
are on the hook for deliverables, then they are at best there to observe.

------
mratzloff
Every daily standup I have been a part of or organized has turned into a
status meeting. The biggest "tell" of a status meeting masquerading as a
standup? When people address the boss, not each other.

~~~
firepoet
What would it be like if the boss wasn't there? I've had good Scrum Masters
hide under their desks if people kept reporting status out at them. The point:
people in authority need to continually work to fight the urge to be "in
charge" during self-organizational meetings.

Also: training/coaching wouldn't hurt..

------
ardit33
I personally hate standups. They are the 21st century version of Chinese
Communist style Daily Morning Exercises.
<http://www.youtube.com/watch?v=o_2C3bvh6ms>

Usually they either are void of real information (as they are supposed to be
quick) and nothing is discussed in depth, or if things do end up discussed
they end up taking too long.

Unfortunately they have propagated in most work places/engineering cultures.

Information should flow naturally between engineers. If you have a jelling
team, people should communicate with each other naturally, without having to
be forced to stand up and listen to status reports (that's exactly what
standups are).

I prefer once or twice a week engineering 30mins sync ups. Short meeting, that
get to the point on whats going on, and you have some time to discuss things
in depth if needed. For any small things, the expectations would be that
engineers should communicate with each other directly.

Instead of having 5 interruptions a week, you have one or two (slightly larger
ones). At the end of the day accountability should be on the delivery of
projects (end results), and not efforts (which standups are more about showing
efforts, rather than results).

From personal experience, experienced engineers tend to highly dislike them,
and the over-reliance on standups is an indication of a weak engineering
culture.

------
jt2190
Both articles lack context, which we're all just filling in with our personal
experiences with standup meetings, hence the pointless "debate" in the
comments here.

I've noticed that developers can be divided into two groups based on whether
they prefer to work with others or by themselves.

Those that prefer to work by themselves take chunks of work that can be done
without input (formal or informal) from their fellow developers, (who they may
refer to as "teammates" despite the fact that they don't work as a team in any
real sense.) For this group, having a daily standup is a waste of time,
because there is no work to coordinate.

Those that prefer to work with others take chunks of work that can't be
considered complete until their fellow developers have also completed their
portions. They seek continual input from their teammates in order to keep
everyone on the same page. For this group the daily standup is just a more
formal version of what they already do informally.

------
manojlds
Offtopic - Hate these "github.com" posts that are actually from some blog
hosted by some random dude on Github. Makes the domain bit meaningless. Wasn't
there some fix for this to show more of the domain in certain cases?

~~~
jaredsohn
Chrome extension: [https://chrome.google.com/webstore/detail/show-full-
domain-o...](https://chrome.google.com/webstore/detail/show-full-domain-on-
hn/hdjpfdgkdgogkebgfogedfhhpiibclpe)

Bookmarklet: <https://github.com/johngibb/Hacker-News--Show-Subdomains>

Edit: Haven't tried them myself; just did an hnsearch. It would be great if
Hacker News would always show the subdomain if not www.

~~~
grimgrin
For the record, tried the Chrome extension and it is only marginally better,
showing you "dshimy.github.com", but not the domain added via CNAME.

------
greghinch
I'm on my fourth team now since 2005 where I have helped successfully employ
scrum, and stand ups are a great part of it. A couple of the biggest mistakes
I see being made are:

1) not correctly identifying "chickens" and "pigs"[1]. Pigs get to talk in a
standup, chickens do not. In fact any interaction with the pigs and chickens
should go entirely through the scrum master (and not during the standup). If
chickens want to come to the standup it is to observe only.

2) conversations. The standup is not the time for conversation. The best
method I've employed is to have each person specifically answer three
questions: what did you do since the last standup? What are you going to do
between now and the next one? Are you impeded in any way? The last one is
where conversations often start. Scrum master needs to stop those, identify
the people who need to talk _after_ the stand up, and move things along.

When you follow those as hard fast rules, standups shouldn't take more than
N*3 minutes where N is the number of pigs.

[1] <http://en.m.wikipedia.org/wiki/The_Chicken_and_the_Pig>

------
johnrob
Standups would make more sense if the team did not communicate during the day.
The reason I think they are pointless is that when a blocking issue arises,
you drop what you're doing and walk straight over to the person who can help
you. I've never seen or heard of someone waiting until the following day's
standup to bring up the issue (which is supposedly what the standup is for,
right?).

~~~
ratherbefuddled
Standups primarily are for making sure everyone knows what's going on.

If you're doing Scrum, the only issues you should really be bringing to
standups are those you can't solve within the team that you need the Scrum
Master to sort out. Anything the team can fix for itself isn't blocking, it's
business as usual.

------
sardonicbryan
Standups work really well when there are dependencies between different
functional groups.

Consider a team working on a live browser/Facebook-based free to play game
(social game as a service). There are many releases a week.

\- Engineering typically requires art assets to begin/complete work. Ie.
building models, unit models, 2D unit images, item images, etc.

\- Releases don't end when they are pushed up to prod -- most releases have
some kind of "go to market" plan that must be executed. For example, if a new
Dragon Armor is released, we need to message all players to inform them of the
new functionality and educate them on how it works, there would typically be a
simultaneous tournament or contest that awards the new Armor as a prize, and
possibly some other sale or promotion on a related item.

\- It's a time for product to provide updates on where different specs are and
on key game metrics.

\- Customer Support/Community Management also provide updates on any emerging
issues in the game, which improves everyone's situational awareness.

------
InclinedPlane
Standups are like communism, great in theory, often horrible in practice.

Of all the standups I've participated in going back 5 years I'd say only one
was any good. It was every other day, it was forcibly limited to 15 minutes or
less, it was always on time, it was never allowed to go off on a tangent, it
only had about 3 or 4 people in it, and it was actively pushed away from being
a status meeting. This contrasts with every other standup I've been a part of
which almost always cut into productivity, and worse. For a while there was a
daily standup with 12+ members that often went for 45 minutes and sometimes
went for an hour and a half.

The problem with a formalized methodology like standups (or agile in general)
is that if you don't have very well defined and explicit reasons and goals and
you don't make that a part of the system then people will just drift into
doing what seems to make sense to them, which is status reports and aimless
meetings.

~~~
bmm6o
A 45-90 minute meeting with 12 people doesn't even sound good in theory. I
know defenses of agile can run into "no true scotsman" territory, but that is
pretty objectively not agile.

Your last paragraph explains why you have to be committed to doing it right.
It's easy to do it wrong, and it becomes worse than doing nothing. But if your
complaint is that doing it right is hard or that you need management buy-in,
that's different than it doesn't work in practice.

~~~
InclinedPlane
That was just the worst example. Most of the other examples ranged from more
or less useless to actively harmful.

As I said, the problem is that the reasoning and goals become too easily
separated from the activity. And then before you know it you've got cargo cult
behavior on your hand.

Wouldn't you know it, the instances where standups were used effectively was
when the team had a lot of experienced people who knew how to work well. A
methodology that is only effective for people who already know how to work
well is not a good methodology in my book.

------
asynchronous13
I think the summary of this could be, "Ineffective meetings are ineffective."

Meetings are one tool among many for team communication, it's just that very
few people are able to run a meeting effectively. I used to believe that all
meetings, in any form, were a waste of time. Right up until I worked for
someone who actually knew how to run a meeting. It was amazing - in a 12-15
person meeting, everyone person contributed, tangents were quickly cut-off,
and they rarely lasted more than 30mins. Sadly, she was promoted (i mean, good
for her, bad for my group at the time) and without her guidance our group
meetings quickly reverted back to a multi-hour mostly useless waste of time.

The lesson I learned is not to dismiss meetings outright. Spend some effort
learning how to run them effectively, and it's still a useful communication
tool.

------
datalus
We run stanups at my place. Everyone keeps their time to talk brief as
possible and we have a rotating leader to keep people out of the weeds. It
works out quite well, so I agree strongly with the article that stand ups are
not a waste.

------
garagemc2
We don't do standups.

Trello does all the communicating.

1) It tells me whats done and what is not, through the checkboxes

2) On larger projects, the guys leave updates in the activity section every
couple of hours or when they hit a milestone or a are stuck with a problem or
are unsure of something. Think of these as like facebook style updates but for
large projects.

These updates are delivered to me in real time. We can then discuss any
problems etc at a suitable time at their convenience or I can pre-emptively
direct them to someone who can help. Unless the problem is urgent in which
case we discuss it then and there.

This way I know what's what and the guys have an open channel to me.

------
Zigurd
If your standups are bad, there are things other than the standup that are
going wrong:

If it lasts too long, the person running it has lost control

If it ends up berating a coder twice a day, every day, regarding a multi-day
implementation task, the person running the standup is an incompetent project
manager

If, as others have given examples of, people zone out, or become
unconfortable, the project has become toxic and the standups can't fix that

If standups adhere to dogma more than they solve problems, the person running
them lacks critical thinking skills and knowledge of project management
techniques

------
kposehn
I'm inclined to agree that Standups can be quite good.

Every morning we have our meeting which maxes out at 15 minutes. The
designated note-taker rotates daily and takes the list of current action items
to be added to RedMine.

The biggest difficulty was fairly simple actually - removing digression from
the mix and also removing things we've completed from the meeting.

There are no side conversations while stuff is being covered, and every day we
sum up what we did in a company-wide email. Other subjects happen offline
between relevant parties. This has been remarkably effective for us :)

------
hermannj314
A few times a day, I say to my colleagues "Want to grab some coffee?" and then
we go to the coffee machine and get coffee. It is inevitable while doing that
we talk about what we are doing, roadblocks, etc. and sometimes we have
nothing to say and we talk about something else.

That works for our team of 4-5, but I understand that it can't scale. Of
course, if management started calling it a stand-up meeting and took away the
coffee, I'm fairly certain we'd get less out of it.

tl-dr; why is a stand-up meeting better than just grabbing a coffee with your
colleagues?

------
djhworld
I'm a developer and not really a fan of standups, I find them monotonous and
dull and often "zone out" after I've said my bit, but I can see how they are
useful to management.

The problem with standups at the company I work for is our team work on
multiple projects so standups end up being just "I'm working on project X and
it's going well, no blockers, cheers!" updates from everyone in the circle.

Standups are probably better for teams working on a single product as everyone
has a stake in what's going on

------
OldSchool
IMO Standups are very useful for a team that works remotely. Placing them in
the middle of the day ensures that nobody's going to have to bend his or her
schedule unreasonably.

Would you rather get at least one extra IM or phone call(?) from each member
of the team randomly throughout the day as you're quietly and productively
working in your own zone?

I'm all for anything that tends to eliminate mental context switching during
the day. Needless to say, not a fan of any office environment for coders.

------
kabdib
My old group started "doing agile." We had daily scrums. They quickly turned
into status meetings for the PMs to bubble up micro-progress reports.

This, on a team with four engineers and three QA types. We sat next to each
other. We didn't need standups, we needed to be left alone to do work.

Finally, on one project the PM (who had appointed himself scrumlord) finally
let us meet only twice a week, and had the common decency to call the meetings
"status".

Call things what they are.

------
knighthacker
I appreciate the author taking the time to write the article, but my opinion
is that the whole purpose of a daily standup is to open a line of
communication between team members. Well, if you have this line of
communication open 24 hours, emails, chat (xmpp, irc ..etc), phone, and so
forth, why do I need to wait till tomorrow afternoon for the scheduled daily
standup to talk about a blocker in my code?

~~~
wpietri
There's nothing wrong with talking more often. It's just to make sure that a
team syncs up on a shared understanding of the state of things _at least that
often_.

------
tosh
Regarding the usefulness of standup-meetings I've written a blog post on how
we do them at Blossom:

[https://www.blossom.io/blog/2012/09/17/3-tips-for-quick-
effe...](https://www.blossom.io/blog/2012/09/17/3-tips-for-quick-effective-
stand-up-meetings.html)

If done well they can be a great facilitator. Just make sure it fits your
culture.

------
dreamdu5t
At my company, we have a HipChat room for "Daily Updates" and an automatic
reminder that notifies everyone to post what they did yesterday and what they
plan on doing today. That's it.

Most people post by noon, and the manager has a written log. It's been working
well so far.

~~~
Evbn
Do you read what people post after you do? That is important too.

------
ender7
This just seems to boil down to well-run meetings vs. poorly-run meetings.
Standups are meant to be light-weight meetings where everyone gets back on the
same page. If that's not happening, then someone isn't running the meeting
correctly.

------
philwelch
Standups, when well done on a healthy team, aren't poisonous. But I've found
that they're rather pointless as well. If you have enough unforced
communication in your team, you don't need the standup.

------
grevutsky
When I first started doing standups, mine were longer than necessary. But as I
got more comfortable and the team's workflow jelled, I've gotten better at
being concise.

------
orangethirty
One on Monday before I start and one on Friday before I leave. That is how I
do it and it works.

------
je42
I am wondering where you guys draw the line between a standup and a status
reporting meeting ?

------
guiomie
"Gareth Rees’ article titled, Standups are Poinonous hit HN" ... I stopped
there.

~~~
Gigablah
"Stopping at the First Sentence Considered Harmful"

------
notjustanymike
Holy crap, he has 3 hours standups? They're called "STAND UPS" because you
stand while giving them so that you're motivated to be quick! I actually try
and follow the one-breath rule for what have I done, what am I doing, what are
my blockers.

~~~
Bootvis
No, he is saying that a 6 person, 30 minute stand up takes 3 hours.

~~~
dasil003
I read that but it sailed right over my head until your comment because that
is an utterly banal observation. Yeah, Microsoft spends 12 man months on
bathroom breaks every single day too; I guess that's why they are going down
the shitter.

~~~
Bootvis
I agree that it is not a very deep point but I think the point is a different
one from the point your analogy make. People go to toilets, slack off and do
all kinds of things during work that are not actually work. Those things are
unavoidable. However, meetings that take too long are avoidable, have a low
value by definition and thus require management action.

------
sareon
What's a standup? I didn't see it defined in either post.

~~~
djhworld
You stand in a circle and listen to people update management on what they are
doing

~~~
conatus
If this is the case, its not being done right. I have heard this happening,
but the standup is for the team, not management.

------
parnas
For my show and tell, sniff sniff, I ...

------
dos1
I'm genuinely curious, how are standups _not_ status meetings?

From the article:

\- Make sure everyone is working on the right thing

\- Help out other team members by taking work off their plate or helping them
by sharing domain-specific knowledge

\- Keeping everyone informed

How is that different from a status meeting? I've heard "standups are not
status meetings" over and over from the agile community, but I don't get it.
They sure seem to be quick status meetings that allow everyone to get a handle
on the current _status_ of the iteration?

~~~
ams6110
I've never experienced standups that weren't status meetings, and weren't
serious flow disrupters. You get to the office, but don't really want to get
too deeply into your work because you know standup time is 9:00. The team gets
together, each person summarizes what they did yesterday, what they plan to do
today, what blockers they have. Everyone else mostly zones out. Next thing you
know 30 minutes have passed, and by the time you get back to your desk and
start to get ready to work you are already thinking "well lunch is coming up,
no point in getting into anything substantial until the afternoon..."

I think standups could work, but they should only focus on things that impact
the project (breaking change to an interface, or significant new things that
are available) or things that are blocking work. And honestly I think email
does a better job at that with a lot less impact on flow.

~~~
pyre
The common thread I see in your complaints about stand-ups are the "I can't
break my work into pieces, I need several hours of intense focus to work on
anything."

E.g., Your stand-up is from 9-930a. After which you can't start anything
substantial because 'lunch is coming,' but that's 2.5 hours away (assuming you
lunch at noon).

~~~
davidwoof1
You're looking at the wrong side of the meeting. It's the time before the
meeting, not the time after.

I like morning stand-ups, but a big problem is that if the stand-up is at 9, I
start winding down whatever I'm doing around 8:30, and I don't start new tasks
after 8-8:30. Multiply the loss by the entire team every day and that's
potentially a big loss of time. And because everyone's schedule is different,
there's really no place to put the meeting that avoids the problem.

The benefits of a well-run standup can outweight this productivity cost, but
it's a real cost that needs to be considered.

~~~
ams6110
Has anyone ever tried an end-of-the-day standup? Would not tend to disrupt
flow, because you're going home afterwards. Also might help keep the gathering
focused and on-topic.

I guess this does presume that everyone wraps up at about the same time every
day, which I've generally found to be the case, but may not work well with
widely distributed workers or places where people actually practice a wider
range of work hours.

~~~
tcharron
I have seem teams use end of day stand-ups. The problem with those is that
they tend to devolve into status updates pretty quickly.

Team members report on what they did that day, but seldom think about the
things they are going to get done next and the things that are preventing them
from getting started on the next thing, which in my opinion, are the more
important things to focus on.

------
corresation
Aside from standups becoming status meetings (which it a mechanism of
superficial management used by terrible managers), one of my gripes with them
is that they're often redundant -- everyone should know what everyone else is
working on, and what everyone else finished, and any blocking issues, via your
agile tool (e.g. Rally). Redundancy in information is a terrible, terrible
thing, and it leads to a situation where neither becomes canonical because
_that other thing_.

~~~
wpietri
In which case, I'd say stop putting information in the tool. We ran my last
company on index cards. You can see a picture here:

[https://www.quora.com/Startups/Which-is-the-best-To-Do-
List-...](https://www.quora.com/Startups/Which-is-the-best-To-Do-List-Task-
Management-application-Any-do-WunderList-Orchestra-Cheddar-Jugggla-Gmail-
Tasks-or-other-Which-also-has-Project-Management-features-tasks-as-part-of-a-
project/answer/William-Pietri?share=1)

The average card had maybe 4 words on it. We knew about issues because we
talked about them.

I love the written word, but it is so much slower and less efficient than
face-to-face communication in so many circumstances. The highest-bandwidth,
lowest-latency human communication system is conversation.

~~~
absconditus
Stop putting information in the tool to create a reason to have stand-ups?

~~~
wpietri
No, have standups to have an easier way to share information than a tool.

------
sultezdukes
Who's doing standups with a 6 member team for 30 minutes? That's nuts.

We're a 6 member team and our standups are typically 5 minutes or less.

We stopped that "what you did yesterday, what you're going to accomplish
today, do you have any roadblocks" rigor nonsense.

We just turnaround to see what's going on. In the beginning, I was pretty
turned off by the rules we were using for standup, but once we stopped all
that, they're pretty helpful, just so we know where we all stand.

My first job out of school, we had a developer that claimed that he couldn't
get any work done around the office because he was constantly being
interruped. Well, his boss let him work from home on this very important
project with a hard deadline. Well, he wasn't checking in and he was being
vague about where he stood. Lo-and-behold, 3 months later he has nothing to
show for, and he's history.

As a previous poster put it, standup can be a canary in the coalmine.

------
static_typed
Standups are a symptom of a failing software engineering disease called
'Agile', which is the real toxin to the system of all healthy developers.

