
Stop the Daily Standup Meeting - struppi
http://devteams.at/stop_the_daily_standup_meeting
======
Meai
In my opinion standups are mood killers. If you need something, you ask for it
anyway. Anything else would be ridiculous, you have a job to do and you need
something from somebody so you ask. This is collaboration 101. Yeah sure,
there is some tiny possibility that person A happens to mention his approach
to some task and person B happens to know a better way, but really that is
such a motivation killer for several psychological reasons, but even more than
that: How likely is that? It never happens anyway and if you know your
colleagues, you likely already know if they probably can help you with
something and you ask them for some pointers. If you don't do that, a standup
isn't going to help you because you don't want help.

So for who's benefit are standups and "agile" in general? It's for the benefit
of managers who by their nature don't have insight into what's going on in
general and they want the most superficial general overview of what everyone
is doing. For developers, I don't see any added value whatsoever. This applies
to all pillars of agile, I could go on and on about this. Agile is only
pseudo-beneficial for managers. Everybody knows everything and then
everybody(=nobody) is responsible when code breaks, giving the manager peace
of mind but the developer couldn't care less: It's not like it was his baby.

~~~
JoeAltmaier
On the other hand, its very common for a team member to get blocked and not
know how to get unblocked. A (occasional) standup can get them past that. And
one blocked team member can quickly become the long pole on the tent.

Standups and agile are quite useful, especially for new teams or teams of
greener developers. Which, in our growth industry, is 'most teams everywhere'.

If you're part of a team that's worked well for months or years, then the
utility is greatly diminished. I think standups can gracefully fade away after
some months.

~~~
Meai
> On the other hand, its very common for a team member to get blocked and not
> know how to get unblocked

Yes of course that can happen and I said so, which means that he should ask
whoever is blocking him how to proceed. If he doesn't know who it is, he asks
the manager and he will direct him to the right person. If there is literally
no way to proceed, he will work on another issue in the meantime and inform
the manager that he's blocked on the more important stuff. If there is some
way to speed it along together with multiple other people, it will come up
when he talks to that first guy. Obviously waiting for the next standup
tomorrow is a ridiculous proposition, so standups solve a problem for 1 time
of the day requiring by definition more people than should be required because
everyone is in it instead of pulling the people in that need to be pulled in
for that specific block or feature.

I don't even know how people defend standups, they usually say something like
"hey yeah, I know it's mostly useless but it's just for 10min a day".
Absolutely unacceptable. Now I get to the last line of your post, and it's
such a relief: "I think standups can gracefully fade away after some months."
Well you should tell the other proponents of standups because I can guarantee
you that this never happens. Standups might be a good idea in the starting
phase of a projects but frankly even then it's debatable and then you would
just call them meetings.

~~~
JoeAltmaier
Green developers can not know who to ask (they're new, right?) or not know
when or how to ask. They can be quite tentative. We're talking Engineers, not
Sales guys.

Some folks don't think they need standups, ok. But in reality, many folks
benefit from them.

~~~
kpil
I agree, even experienced developers can get stuck barking up the wrong tree.

There are at least one or two exchanges like this every week in my team:

    
    
        Dev A: - I'm working on X, and will just need to fix the code for Y to handle it. It's a bit messy but I'm probably done tomorrow.
        Dev B: - Eh... I think you need to do something to the Z code, we can take a look after the meeting.
        Dev A: - Sure.

------
algesten
We (the developers) took control over our standups. We went back to basics and
talked about _why_ are we doing kanban boards standups, and found two reasons.

1) We do need better awareness of what others around us are doing, especially
across the dev/ops divide. 2) Communication, kanban is there to show
interested non-devs how projects are progressing.

We update the kanban before the meeting and let one person per day read
through the entire board for today/ongoing/blocked. If there are any tasks
that person doesn't understand – this is the time to ask.

The process takes often less than 10 mins per day.

Any issues raised will be discussed in loosely formed groups afterwards to not
waste everyone's time.

I think what I learned is that you mustn't let process be shoved on you by
middle management. Take control to make these things productive for you.

~~~
mianos
We have a slack channel. You write what you did yesterday, what you are going
to do today. If you are blocked, what is blocking you. When you expect to
deliver what. Everyone does it. As a reader, you skip the stuff you don't care
much for. Pretty interesting though. Maybe ask someone for further
clarification. Works great. I like to do it just before I leave for work. The
only issue is some skill-less turkey with a title 'coach' can't make a buck,
but I am sure he would pipe in and tell us we are doing it all wrong.

~~~
jakozaur
In fact we write plan for today on Slack and later modify me message to change
what actually gets done.

It is great because:

1\. Most of the time you skim the list, but sometimes want to follow up and
collaborate. It helps ppl keep on same page and avoid redoing the same stuff.

2\. Async, written as first thing when you come to work.

3\. Writing todos and sharing them helps ppl to get focused and make them
productive.

------
awjr
"When it gets cancelled because a certain person is not there, you are doing
the meeting for that person"

This rang true with my current team. It isn't that the meeting doesn't happen
but it is extremely fast. No round robin, just a simple 'has anyone got any
issues'. Nope, ok carry on. We still get high value from those discussions.

My personal observation is that when this senior person is there, they are
using the stand-up as a project management meeting. This should really be
'taken offline' and this person should be working with team leads away from
the stand-up.

Luckily I'm working closely with one of the team leads in an isolated area and
I excuse myself from the meeting and let him talk on my behalf but I shouldn't
be at that point where I'm trying to avoid them.

The other day 8 people did a stand-up for 27minutes. That's a crazy loss of
time.

~~~
onion2k
_The other day 8 people did a stand-up for 27minutes. That 's a crazy loss of
time._

It's not necessarily a loss of time though.

The mindset "any time spent doing things other than writing code is a waste"
rarely produces great products - you _need_ to talk about things. No one knows
_everything_ about a project once it gets to a even moderately large size.
Working in isolation from the rest of your team means you're not influencing,
or being influenced by, the knowledge and discoveries that other people are
making as they work. That means you're very likely to be working with an out-
of-date model of the problem you're trying to solve.

Clearly a meeting where nothing happens _is_ a waste of time, but the solution
to that problem shouldn't be "no more meetings", but "better meetings with
real outcomes".

~~~
pjbster
It's more than a loss of time - there's also the context switch and attendant
energy expenditure to restore the "head space" after escaping the meeting.

If the discussion can add more value than those costs, then go for it.

~~~
criddell
We did stand-ups at my previous employer and for some reason they happened
early in the morning. That's my most productive time. I always thought we
should move them to after lunch or maybe later in the day. In that office,
productivity and energy definitely dropped as the day wore on and it seemed
foolish to spend some of the best time in discussions.

~~~
mixmastamyk
I had the opposite problem, but it was a morning problem also. First thing in
the morning, I am very foggy, and remember very little from yesterday. It is
not until I've worked for an hour or two that everything comes back. Paged in
from disk, so to speak.

So I often had to make things up on the spot to sound busy when I had no idea
what happened yesterday at the crack of dawn. What a waste of energy.

------
rosalinekarr
I'm seeing a lot of comments about how terrible different people's standup
meetings are at their particular companies, and I can't help but think the
problem isn't with standup itself, it's with these companies.

At my job, we meet for standup via video chat as early as we can. That's about
9am for some of us and 10am or 11am for others depending on timezones. We each
say what we worked on yesterday and what we're working on now, which only
takes about 5 to 10 minutes, then we enter what we call "parking lot." We call
it "parking lot" because if this were an in-person meeting, this is bit where
we would be talking in the parking lot on our way out to lunch. No one is
expected to stick around unless there's something urgent related to what your
working on that needs to be discussed. Anyone is free to hop off the call at
this point.

During parking lot, we discuss impediments, anything that's going to keep
someone from getting work done that day. If the problem is something
complicated that's difficult to describe via text, we chat about it face to
face and work out a solution together. If the problem is simple, we just agree
to talk it out in either a public or private channel on Slack depending the
kind of problem.

The purpose of the meeting isn't to build a big report of who's working on
what or to guilt us into working harder. It's just to guarantee that we're all
online at a given time each day to help each other out. Working across several
timezones, we all have wildly different hours, and without standup, we would
probably be waiting for days to hear back from each other about any issues we
run into.

Maybe standup is a problem for other people or other companies, but for my
team at least, we couldn't work without it.

~~~
vikingcaffiene
Couldn't agree more with what you are saying here. Daily stand ups, if done
right are very helpful especially for remote teams. I did daily stand ups at
my previous company and they took on average an hour and were unfocused,
meandering and generally pointless. I dreaded them and the whole team felt the
same. By contrast, my current team is much larger but keeps the daily stand up
to 15 minutes. It's focused and everyone is on page about tabling longer
discussions for post stand up with the relevant stakeholders. While I won't
ever say I'm looking forward to it, I see the tangible benefits. We are a
remote team across multiple time zones and are able to effectively work
together with ease. The daily stand up is a big part of that.

------
expertentipp
The effort to say something about yesterday and about today is an obsolete
overhead. Sometimes one is just stuck for couple of days with bloated and
partially obsolete Java setup, sometimes one has done nothing and needs a
break instead of daily confessions. Saying these might be perceived arrogant
or disrespectful. I perceive standups as an immature way to discipline
developers.

~~~
bshimmin
I really don't see why it has to be that way, and if people feel like that,
there's something weird going on.

If you've been given a large feature that involves, say, analytics, there is
surely nothing wrong with your standup contribution being:

"Yesterday, analytics. Today, analytics. Yes, I said the same yesterday, it's
a big job, but it's going fine. Anyone can come over and ask me about
analytics if they like! No blockers. Thanks."

It tells people what you're doing and that it's broadly going ok. If you're
five days into something that was supposed to take three days and you're
actively embarrassed about this, then that's a problem - but it's a problem
that should be discussed at the end of the third day with the stakeholders,
not in the standup.

~~~
rejschaap
The problem is you feel like you need to justify working on one thing for two
days:

"Yes, I said the same yesterday, it's a big job, but it's going fine."

and, this is even more defensive, you feel people will not believe you so you
invite them to see some proof:

"Anyone can come over and ask me about analytics if they like!"

Maybe the biggest problem is this though:

"Yesterday, analytics. Today, analytics"

This task needs to be broken up into manageable pieces badly.

~~~
matthewmacleod
_This task needs to be broken up into manageable pieces badly._

This would also be my immediate thought as well. "Yesterday I setup
integration with the analytics service. Today, I'm going to audit the places
where we currently send analytics and see if it would be possible to
centralise it – I'll share the results later".

It's hard to track progress and estimate if your tickets are huge multi-week
affairs.

~~~
sheepmullet
Is it really important to track progress on a day to day basis?

IMO, only for a small minority of tasks.

The vast majority of projects I've seen and worked on are measured in dev
years of effort.

My current project is well over a thousand dev years.

In comparison a few days is meaningless.

Most often it's a trust issue.

~~~
jakubp
A thousand man-years of effort? Sounds like a very large project.

Just for contrast: I've been working for a medium size software house for the
past 4 years. Typical project size is somewhere around 500 to 1000 man days.
On that scale, individual days matter.

Still, I also have the impression that they matter because Clients demand
certainty and precision in reporting rather than focusing on actual value
delivered, but the management doesn't always see it that way.

~~~
sheepmullet
> A thousand man-years of effort? Sounds like a very large project.

Kind of. It's upper-medium.

It's nothing compared to Microsoft Office, a web browser, etc.

Microsoft for example has maybe 50k developers and so creates 50,000 man years
of work every single year.

> Typical project size is somewhere around 500 to 1000 man days.

That's roughly 2 devs for a year. That's hardly even a prototype where I work.

It is fascinating to see the difference in scale in our industry.

------
TimJYoung
Team-oriented software development has become somewhat infantilized, and it's
a worrying trend that keeps showing up in our society, in general.

We need to stop approaching team development with the _expectation_ that one
or more team members will need checking up on because they're goofing off too
much or not working on what they're supposed to be working on. Professional
software development is a _career_ , and we should be able to start all
employer <-> employee relationships with the expectation that a) we're all
adults, and will treat each other accordingly, and b) we're all, ultimately,
responsible for our own work and the work of the team. If someone repeatedly
demonstrates that they can't execute in this fashion, then they're gone.
There's simply too much to do, and dragging the entire team down to the level
of the least-responsible member is ridiculous. You're better off just
distributing the extra work among existing team members.

For example: want the team to bond and communicate ? Ditch the daily meetings,
and every Friday take the team out for a meandering late work lunch where
everyone talks about the week, what they're working on, the overall project,
etc. Any other time, everyone knows where the other team members are working -
if there's something that you need, you ask in the least-intrusive way
possible, depending upon how busy the other team member is and the importance
of your task.

------
ealexhudson
I disagree with the basic premise of this: "When it gets cancelled because a
certain person is not there, you are doing the meeting for that person".

One person being the driving force behind making something happen doesn't
imply that all the benefit accrues to them at all.

"Just make sure everyone is actually recording what they are missing!"

Except they have no way of recording the opportunity cost - they don't know
what they haven't been told; they could be missing something huge, but without
a venue for communication they don't find out.

I have to say, I don't think this is great advice.

~~~
ozim
If it is cancelled then he is right, if it is more like there is no one in the
room who comes up and calls for standup then you are right.

------
mdekkers
I do some contracting from time to time with a devshop that has gone "full
agile" \- I love these people, and have a lot of respect for the work they do,
but OH. MY. GOD. save me from the fucking standups. What a totally useless
waste of everybodies' time. I refuse to attend most of them in any case, which
harms my standing with the project managers, but I seriously don't care - most
standups as well as the majority of other project management activities they
practice appear to be designed to keep the project managers happy, and
contribute little to the overall quality or speed of delivery of the project
at hand, and are a massive distraction to everyone involved. Daily
$project_management_ritual should die.

------
borplk
Daily standup is a scam just like the "open office".

Most of the time it turns into a beating stick for incompetent managers to
feel good.

They are both defended by people for various superficial theoretical reasons
that never come to fruition.

Like they try to defend open office because "it's good for collaboration" but
in reality it's only to cut down office costs and to let employees watch each
other.

If giving people private offices was much cheaper you'd never in a million
years see a company accept the increased cost of an open office just because
"it's good for collaboration".

This is a pattern that you can notice easily in business. Anything undesirable
that is not good for you will be applied a lip-stick of colorful language in
order to "sell" it to you and it goes right into the echo chamber.

You can put people in boxes that stack on top of each other and then say "Our
beautiful stacked-box office promotes a culture of deep thinking and solitude
where you can re-gain your focus and stay away from constant distractions.".

~~~
dasmoth
_If giving people private offices was much cheaper you 'd never in a million
years see a company accept the increased cost of an open office just because
"it's good for collaboration"._

Were this testable, I'd absolutely take the other side of this bet. (Some)
managers get too much satisfaction out of seeing their "doers" lined up and
visibly working. And/or believe that watching one another makes people work
harder. Open offices would happen, even at a premium.

Edit: actually, it kind-of is testable. If office costs were the biggest
factor in how workers were deployed, we'd see _far_ more remote work.

 _You can put people in boxes that stack on top of each other and then say
"Our beautiful stacked-box office promotes a culture of deep thinking and
solitude where you can re-gain your focus and stay away from constant
distractions."._

Please tell me when you open one of these, I might be after a job!

------
gdulli
I've been at my current job for 5 years and spent my previous 15 at 7
different jobs combined. It's not an accident that I've stayed at this one but
left all of the others. This is the one where people are allowed to be
responsible for their own productivity without overhead like standups, project
managers, status reports, task tracking software, etc. It couldn't work for
all people or all companies, but it means enough to me to manage my career
around finding the environments like this one that make me enjoy coming to
work so much more.

------
foxylion
In the aspect of scrum the daily is good defined, I don't think you need to
experiment about what needs to be talked about.

It is a one time a day meeting where everyone gives a glimpse over what he has
done and how this may affect others and what he is going to achieve until the
next meeting. Committing to a goal motivates me to get things done. A third
aspect is to give the scrum master feedback about impediments which do prevent
me from achieving my goals.

And yes this does not mean that nobody is talking to each other through the
day. But even if you are a team it is important to get everyone up to date.
Most discussion through the day happen between 2 or 3 persons, and not with
everyone (4-6 people).

------
scalatohaskell
I agree with author... instead of doing "Scrum", how about we act like adults,
and speak with people when we need to, in respect to their time, schedule
accordingly, and not clown and parade around with scrum and poker cards.

[http://programming-motherfucker.com/](http://programming-motherfucker.com/)

~~~
matthewmacleod
Ugh, this attitude is just the worst.

There are a whole bunch of legitimate reasons that aspects of Scrum are useful
to some teams. Like the planning poker thing –I work with a team of talented,
experienced and professional developers, and we _still_ have misconceptions
about complexity that are revealed by the planning poker approach.

The idea that 'if everyone just programmed it would be fine' is totally
asinine.

~~~
scalatohaskell
that's not how I meant it. Sure, plan it, however it suits you and the team.
If planning poker works for you, great. But do you need to coat it under
"Scrum", having special moderators such as Scrummaster and consultations every
year how you are not doing scrum "enough". I don't advocate programming
anarchy, but I don't like when managers treat programmers like some
woodchoppers that they need to wrap fine grained process around, instead of
having the team work the way it fits them best.

~~~
matthewmacleod
I completely agree that 'agile' without being agile is just buzzword bingo,
and I've been through it myself. Ultimately, plan however works for your team.
But I do get the impression generally that there can be a lot of unjustified
resistance to any kind of organisation among certain groups of developers; it
pays to be open-minded about techniques that can work.

~~~
scalatohaskell
I think the resistance is not unjustified - mostly programmers are fed up with
"these" things, since they always get misused against them (i.e. - estimations
- you and me know how it works, that it's well, estimation - but in back there
is manager who translates it in his excel to $$$ and time, and the second your
8point story is now day overdue you are being pushed to zones which only
further damage the project down the road (costs which you will have to pay by
overtimes, not the guy behind his excel). Does that mean estimation is bad?
No. It's non-programmers who misuse it. Would team be better without
estimation? Probably, since it wouldn't be misused by external elements, and
we could just do our damn job).

Perhaps the original agile was meant correctly, but as of today most
organisations just use it to justify and coat (perhaps) same things agile was
to be against.

For me today Agile has so way too many faces. If it doesn't work, answer is
always "you're not doing agile/scrum correctly). There are always reasons how
you're not being agile enough, no matter how many times you fine-tune your
"agile" on retrospectives, if there are managers and people misusing it
against you, you could as well be better without it.

What an incomprehensive piece of text I wrote. Sorry. I'm not native English
speaker.

If you're lucky non of this applies though, but you have to be lucky enough to
work with lots of (prehaps we might say all) smart people across whole "chain
of command".

~~~
Chris2048
When they ask for an "estimation", they are actually seeking a "quotation".

------
kabdib
Our "scrum" stand-ups were taken over by the PM stack, and they started
getting longer and longer and weren't useful for the team doing the work.

So I started calling them status meetings.

"Hey, stand-up in five minutes!"

"You mean status?"

... and kept doing that. Eventually even the PM grudgingly admitted that it
was just a status meeting, and referred to it that way himself.

It was okay; agile had died (and turned into simple micro-management) a long
time ago in our division.

------
JackMorgan
As a counterpoint: stand-ups can be a great way to operate a team without a
managers, tech leads, or assigned work: [http://deliberate-software.com/self-
organizing-balance/](http://deliberate-software.com/self-organizing-balance/)

I think "bad stand-ups" is a symptom you are using a self-organizing practice
in a command-and-control team.

~~~
watwut
Self organization means that multiple wanna be dominant devs will attempt to
make themselves leads - leading to ugly politics and constant attempts to
micromanage other team members.

Single clear and accountable leader is much better way.

~~~
JackMorgan
You've shown one way self-organizing teams can fail. That is not true for all
teams.

I can similarly show a way a clear, accountable leader can fail: they can be
good enough at politics to make a huge, micromanaged mess yet have all the
blame placed on their team and get promoted. Just because sometimes it does
happen, it doesn't mean it always happens ;)

~~~
watwut
Self organization witout accountability works when all of you are perfect and
there is no pressure or blame game going on. It works only rarely. There are
bad and good managers obviously, but most bad managers basically force team to
self organize.

In any case, it takes only one team member to be aggressive micromanager in
order to blow self organization in hell.

------
danielbln
We have switched to asynchronous, slack-based standups a long time ago,
moderated by a bot (we're using a modified version of
[https://github.com/eelzon/morgenbot](https://github.com/eelzon/morgenbot)).
This way everyone knows what everyone else has been up to, will be up to and
what blockers are, without being caught up in endless discussions, and since
it's asynchronous, people can supply their standup (within limits) at their
own leisure. Works well for us.

~~~
epalmer
Apologies if the repo makes this obvious. I'm on my phone. Do you maintain a
virtual scrum board? What software do you use and how do you like it? I am on
small scrum team and we all would like to go virtual for many reasons. Mostly
we are from different parts of campus and the travel time eats productivity.
And many of us have families that get in the way of the morning standup. A
virtual one can be done from anywhere. Thanks for any help.

~~~
danielbln
Yeah, we are using Trello to coordinate our tasks/stories, and have been quite
happy with it.

------
ryanmarsh
As a coach here's my question about the standard standup format (what did you
do yesterday, etc...)

If the reason we are all here is to get the work done why is it ok that it's a
mystery what is done or not? Why is it not obvious? Why do we have to ask? Why
not just keep your board or whatever up to date and talk about other things?
Like surprises, blockers, questions, or concerns.

~~~
noxToken
> _Why not just keep your board or whatever up to date and talk about other
> things? Like surprises, blockers, questions, or concerns._

I could be wrong, but I think that might have been the original intent.

Enumerating everything work related you did yesterday is a waste of time. "I
worked on X, Y, and Z. Y and Z are closed. I still need to finish up X," tells
nothing that the board doesn't tell. If Y and Z are closed, _Y and Z 's status
reflect that on the board_.

"X is still unfinished. An external dependency from ${team} is failing, so I'm
coordinating with ${point-of-contact} to resolve the issue." That is a
worthwhile update that takes the same amount of time yet contains infinitely
more information.

Maybe we need a new format. Everyone who speaks could start with, "Everything
I did was routine except..." We know that you went to a meeting with another
upstream team, because you have that same meeting at the same time every
Tuesday. Therefore, we don't need you to say, "Yesterday I went to a meeting
with ${team}." Give us the meeting details that's relevant to our team. You
then drop the preamble after a few days or so.

~~~
ryanmarsh
I think you're right, I think it was the original intent. Seems to be lost on
quite a few coaches though

------
don_draper
I haven't done standup in 6 months and I just feel generally better. Where I
work you just report to the tech lead every 2 or 3 weeks. So much nicer than
daily standups. Could you imagine other professions doing what we do?

~~~
dasmoth
_Where I work you just report to the tech lead every 2 or 3 weeks._

Sounds pretty much perfect to me (although I also know people who would go
stir-crazy like this...)

Can I ask: what sort of company is this? Dedicated software operation or a
tech department inside a company doing something else?

~~~
don_draper
It's an engineering company that does math/science stuff along with regular
software development.

------
Chaebixi
> Stop the Daily Standup Meeting

Please yes! _Especially_ the more dogmatic ones (e.g. _only_ stating what you
did yesterday, what you're going to do today, what's blocking you). It's just
an empty status reporting ritual that feeds some negative emotional need of a
manager (either anxiousness or a need to feel directly in control).

Personally, I think a freeform dev team meeting that happens 2 or 3 times a
week is much more valuable. For instance: if there's a big issue going on,
lets actually talk about it rather than merely stating we're working on it
(and taking "offline" the only information others might actually be curious
about).

------
johan_larson
I've worked both in a standard office setting and remotely. When I was in-
office, I found the daily stand-ups tedious, because everyone was telling me
stuff I was already aware of. But now when I am remote I find the stand-ups
much more useful, because they are telling me stuff I don't already know. It's
like stand-ups are overkill when the team is already working together in close
quarters.

------
scorpioxy
Stand ups at an agency I am currently working for on a short term engagement
just has people in the tech team listing what clients they're going to be
working for today. You know, because that's very helpful for everyone to
know....

I think the spirit of agile development is lost on most places and blindly
sticking to process without questioning it becomes the norm.

------
user5994461
Never do daily meeting. Never accept daily meeting. Never participate in daily
mettings.

That's simply too frequent.

People will spend all their day thinking about what they will present the next
day instead of doing actual work.

~~~
taneq
If you're working in an interdisciplinary team you _need_ to know what the
other groups in your team are working on. Maybe if you're doing deep research
or something, you can hide in your cave and focus purely on your own work, but
if you're doing implementation rather than research, you have to understand
all of what's going on.

~~~
dagw
_If you 're working in an interdisciplinary team you need to know what the
other groups in your team are working on._

Sure, but does everybody need to be updated every single day? And does that
update have to take the form of an all hands meeting?

------
Samathy
I found out yesterday that a new colleague who is transferring from another
department is used to having mandatory hour long daily standups.

We were all shocked that a manager could justify wasting that much time every
single day.

We have no standups since we all work on different projects, we don't really
need to know what everyone else is doing.

------
cavanasm
I'm a junior developer in a "Scaled Agile Framework" (SAFe, apparently) team
at a VERY big company, and although we never cancel our stand ups, the format
seems to exclusively be for status updates / reporting, and not "for the
team". Feels like everyone else is habituated to it though, and they don't
seem to mind, but it definitely bothers me. Generally lucky if a morning stand
up takes 30 minutes, let alone 15.

------
dkhenry
I found the best way to make a standup successful was to put a hard limit on
how long people could talk. When my teams were working the best they had a
limit of 15 seconds ( I would count down while they talked ). The stand up is
situational awareness not status of ongoing projects. Once the 15 second round
of updates were done, if there was someone I needed more information from I
would grab them after the standup to talk to them.

I don't really understand how a team can have a 30 minute standup, to me that
is a manager who is lazy or disconnected who doesn't bother to follow the
teams progress on the myriad of tools they inevitably have ( Whiteboards,
Jira, Github, ..... )

~~~
lojack
I would refuse to go to any meeting where I was asked to talk and then had
someone counting down from 15 the second I started. I understand why you're
doing it, but it comes off as rude and demeaning to me.

My stand ups are time boxes at 15 minutes total, and the person running the
meeting cuts it off at 15 minutes even if people haven't had a chance to talk.
If you have something to say you don't have to cram it in 15 seconds, but
often people just pass. It only takes a few meetings going over 15 minutes for
habits to adjust.

~~~
dkhenry
the countdown is necessary because its rude and demeaning for someone to take
up everyone time by talking longer then they should. In a perfect world we all
agree to the rules and follow them, but like you said even at 15 minutes
someone has to cut everyone else off. Its the same principle applied at a
different level. You time box the whole meeting and someone is rude and
disbands it before everyone has talked, or you time box each person and
everyone gets a chance to talk. In an environment where you have a mix of
strong personalities and more introspective people the folks who are more soft
spoken will be drown out if you don't specifically allot them time to talk. At
least that has been my experience

~~~
lojack
It's the counting down part I consider to be rude and demeaning. In addition
to that I feel like it encourages people to cram as much as they can into as
little time as possible, which kind of defeats the purpose. The goal of time
boxing in my opinion is to be a signal that you're doing something wrong.
Realistically, you shouldn't ever hit the limit.

The cutting off of individuals vs teams is something we could debate, and I'm
not sure either of us would be right or wrong on. I see your point of strong
vs soft spoken personalities, it's not something my team personally deals with
so thats probably part of the reason more free form meetings work for us.

------
Beltiras
I'm in a small team. I am the lone coder and I report directly to the CEO. I
asked to do a standup because it's imperative for me to gain focus on tasks
and frame my work. We used to have weekly status meetings but that was too
infrequent. Instead of a weekly half-hour we now do 2-5 minutes of me standing
in his doorway running through the "Yesterday I worked on [tasklist]. I am
[not] stuck. I [don't] have resources for my tasks. Today I commit to work on
[tasklist]."

Standup for me is making me accountable.

------
themtutty
Ugh. Provocative, radical idea that is founded upon overly-simple, faulty
assumptions. To think that the author's three categories for teams are the
only three, and that standup communication only takes the forms he describes
is just hubris, and leads to dangerous advice.

~~~
lojack
The author identified three potential pitfalls of stand ups and suggested not
doing them if you fit into those three categories. Title comes off as a
blanket statement, but I didn't get that feeling from the rest of the article.

------
flurdy
Appreciate the OP is about whether the stand up is for the scrum
master/project manager etc or for the team members. Hopefully it is both, and
mostly the later.

Also see in the other threads (and discussion in general) that mistakes the
standups as for reporting your status to managers. That may be required in
some organisations or partially, but not in most.

But I would view a good stand up one that does NOT require each team member to
in turn state the old: "what they did yesterday, what will do toady, any
impediments".

Instead you hope project leadership trust their team members and instead focus
on the tasks. In order of task priority a participant in that story can
quicklyy broadcast if anything has changed with a task/story, no need for
details of what happened yesterday, no need for whom did what etc. Then if any
impediments for that story, escalations, anything else etc. And just quickly
rattle through them to make sure focus is maintained on getting the tasks
flowing through to delivered.

TL;DR focus on tasks not people reporting. I ranted about this some years
ago... [http://blog.flurdy.com/2013/04/i-dont-care-what-you-did-
yest...](http://blog.flurdy.com/2013/04/i-dont-care-what-you-did-
yesterday-i.html)

------
kornakiewicz
Basically:

\- if it's a status/reporting meeting - don't do it, there are better tools.

\- if it's knowledge transfer meeting and it benefits a whole team - do it.

------
TheAceOfHearts
In my old job we used Geekbot [0], a Slack bot for async standup meetings.
It's great for geographically distributed teams.

I found it made it much easier to get an idea of what people were up to, as
well as providing an opening for occasional tips and suggestions. Posts
typically included a mix of what you achieved, what you hope to achieve, and
any blockers. Any updates or big breakthroughs were usually shared as well.

I think it's best to be flexible about how frequently status updates are
shared, leaving it up to the developer's discretion.

[0] [https://geekbot.io](https://geekbot.io)

------
geori
The point of a standup is to coordinate team communication in batches and not
interrupt people at random times. We always finish it up in less than 15
minutes and then small groups meet afterwards about talking points.

~~~
lawnchair_larry
Whenever you decide to have a standup is a random time for some people.

For some, it will be too early, prematurely terminating their sleep cycle and
rushing them in, probably leaving them below peak cognitive performance for
the entire day.

For others, they are already in their awake-and-productive time, and they'll
either have to stop to join, or they will simply waste time until the meeting,
knowing that an interruption is on the way, and being preoccupied with those
thoughts.

To work as a team, this is going to happen here and there, and that's fine.
But to do it daily as a ritual is an incredible tax on your human capital for
no good reason. Not only that, but you're filtering out your talent pool to
folks who don't perform at their best under these constraints. From what I
have seen, these can often be very high performers.

------
htsh
I can see the value of the standup but I find daily to be too often.

The best teams I've worked with have staggered them to either M-W-F or T-R,
primarily because the work we do require more than a day. And depending how
one works, a daily standup every morning makes it tough to get a good night's
work in.

I often point people to PG's relevant essay during discussions about this:
[http://www.paulgraham.com/makersschedule.html](http://www.paulgraham.com/makersschedule.html)

------
yeukhon
I used to like standup because that's the only time I have to see what my team
is soingnsince most of them are remote and working in a different time-zome.
It was a great way to give tips and do the "okay let's talk about this offline
afterward."

But now I hated it. Not only rhe standup is mismanaged ao badly, I also don't
have much to update on a daily basis which means I feel useless if I have
nothing to say or have little progress on my tickets.

------
Floegipoky
No way, my team gets a lot of value from our standup!

We have 5 devs. We have a scrum master, but we rotate who's facilitating from
our lead down to our most junior dev. If our scrum master's out it's no
problem, any one of us is able to step up. The first ~10 minutes or so are
spent updating the team on the progress we made yesterday and making sure
everyone knows what they're working on today. Pretty standard fair.

But we always take a full 1/2 hour. We use the rest of the time for backlog
grooming. It works really well for us for 2 reasons: 1\. We get a lot of
reactive work, and it's really convenient to have time set aside every day to
address it 2\. By piggybacking backlog grooming onto time that we're already
scheduled to be together as a team, we cut down on the number of other
meetings we need to have (and context switching to/from coding). We all find
it much more convenient to spend an extra ~20 minutes together every morning
so that we can have the rest of the day to work.

------
edpichler
People, I respectfully do not agree with this blog post.

How people can notice that work is not being done if they don't do meetings?
How to assure they are communicating correctly? How to prevent a bomb explodes
a day before the deadline?

If you discover problems close to the deadline, you already have a big
problem. My opinion is that these daily meeting are to prevent problems, like
integration between systems.

People are comfortable on their own doings, they don't like meetings, they
prefer a problem occurs and share the blame than doing daily meetings. We must
do daily meetings because it's good for the project and not because we enjoy
it, we do to avoid that some lazy or introvert collaborator don't share a
problem that can affect everybody.

That's why we have a scrum master to do the dirty job and assure everyone is
talking each other.

~~~
Ace17
> That's why we have a scrum master to do the dirty job and assure everyone is
> talking each other.

Encouraging communication is a great goal ; but trying to force it on a
regular basis might have the contrary effect.

~~~
edpichler
It's complicated. Who decides if it's necessary? Most of people prefer to stay
on their comfort zone, that is why I think the team must follow some rules.

------
alienreborn
I actually like the way we do stand ups at my current job. All of us sit
together, so we just stand up in place and state what we are working on and if
we have any blockers that need to be taken offline with specific ppl. Whole
thing will be done under 2mins.

------
samblr
In regular corporate settigns, I see these standup meetings are a way to
simply make information flood across organisation hierarchy. A good leader can
then parse and make sense of signal amongst plenty of noise. But it does
rarely serves that purpose. We used to 've standup of 10 members several years
ago! Since then I kind of developed disliking towards regular meetings.
Currently we 've a trello-kanban updated so that we've information flowing.
And a weekly mail with traffic lights, explaining current-and-next week
activities - working well so far.

------
mixmastamyk
Worked on a team just like described, all on different projects. It was
infuriating, the boss interrupted me every morning at ten, just as I was
entering the "zone" for a no value (to me) standup.

------
drinchev
Having a >short< daily meeting is important part of any dev-team.

Goals are:

1\. Discussion on who's doing what ( details )

2\. Discussion on who did what, since last meeting.

3\. Help / suggestions based on the conversations above.

~~~
martijn_himself
Having just finished a 5 week agile project with daily stand-ups I found:

1\. I'm already aware of what everyone is doing which is relevant to my own
work outside the daily meeting. Everything else is just noise.

2\. I don't want to know what someone else did since the last meeting unless
it was relevant to my stream of work, in which case I already know about it.

3\. See above.

Needless to say I found the daily stand-ups a complete waste of time.

~~~
aembleton
\- Other works streams might not affect yours, but don't you find that it
helps you to understand aspects of the project that will affect future
workstreams?

\- How do you or they know that it will have no affect on your area without
the daily stand up?

\- If someone is experiencing a blocker, you might have come across the same
issue earlier in your career or even last week. Then you can help them.

~~~
martijn_himself
These are all very valid points but I don't feel the need for a daily stand up
to achieve them! Effective communication and meetings already achieve these
things.

~~~
aembleton
If your team has effective enough communications to not require them, then I
guess they're not for you. For me, that has never been the case in any team
that I've worked in.

------
sbose78
It's fair to _ask_ the team how frequently they want stand-ups. It could be
daily or it could be weekly.

Without _asking_ , standups are counter-productive.

------
mfukar
Right now my team are trying out only doing standups if there's important
stuff to share. This leads to 1-2 standups per week for the past month.

Tidbits of info which can be shared at a glance, and probably don't affect
anybody's workflow, go on a whiteboard. That way we know everybody's status,
and seems like we can share important info when it matters.

------
sidcool
Not very convincing. But standups should be tailored for team needs, rather
than imposing a standard. And I don't get the role of a Scrum Master. Good
article overall in terms of encouraging discussion.

------
relics443
My company did standup for 3 years either in person or over hangouts (once we
became distributed), and recently switched to an async model over slack. Much
better engagement, and much better quality updates.

------
smizell
For those who do daily standups via a Slack channel, I made a little tool to
help me.

[https://www.npmjs.com/package/onit](https://www.npmjs.com/package/onit)

------
JetJaguar
[https://www.youtube.com/watch?v=nvks70PD0Rs](https://www.youtube.com/watch?v=nvks70PD0Rs)

------
DorothySim
Also relevant: [https://vimeo.com/110554082](https://vimeo.com/110554082)

------
itomato
Tracking systems and wallboards should suffice.

In absence of those, a 15 minute Standup seems (woefully) inadequate by
comparison.

------
timwaagh
stand up has to be the one good thing about scrum. the rest is just boring
meetings which cost too much time entirely. but 5 minutes i can spare each
day. the daily accountability it brings keeps managers from firing me (i have
been fired way too many times often in the first week) as they know what i'm
doing and therefore dont think i lack motivation. it also motivates me to
perform even better.

i dont think standup is bad at all and i think managers should be present for
it. it may not be for some kind of idealistic 'for the team' thing or even the
original intent, but... standups are a good thing. even if you're not doing
agile, standups can still be useful to keep managers informed if you are a
larger team (>3 people).

------
douche
The standup meeting can burn in hell. It's a lovely bit of useless
micromanagement. Consider:

If you're organized at all, there should be notifications going out when
anyone on your team commits code, or comments on tickets, or whatever. If your
communications are so dysfunctional that you need to have a defined point
every day to apprise people of what is going on or ask questions of your
teammates, focusing on that root problem would be more effective than band-
aiding it with a daily standup.

There's never a good time to schedule it. No matter when you do so, it's going
to frig someone up and waste one to two hours of productive flow time, at
best. First thing in the morning doesn't work, because people run late. Later
in the morning, and you might as well kiss the whole morning goodbye for
productive work. At the end of the day, it will inevitably run over and piss
off everybody who needs to get the hell out of the office and take care of
their personal obligations at the end of the day.

There's always one or two people that want to ramble along and narrate every
little thing they did in excruciating detail. Or that want to turn an issue
that turns up relevant to two people into an interminable status/planning
meeting on that issue. Mostly, I'm just not convinced that there is any way to
do a standup meeting _right_ , so that it is useful for it's stated purpose
without being more costly than it is worth.

If you need this kind of fine-grained progress reporting, have everybody send
an email or a group chat with the three standup kindergarten circle-time
questions answered. Then if there is an actual need to meet and go over
something, you can identify the relevant people and not waste everyone else's
time.

We ditched standup meetings a while back. It's been glorious.

------
nimchimpsky
Don't have them at all. Suits me just fine.

~~~
khazhoux
BUT HOW DO YOU GET ANY WORK DONE WITHOUT STANDUPS??!?

~~~
OskarS
You work. You do your job. If you're unsure about what task to do, you speak
to your manager. You know, how offices have worked for the previous hundred
years.

~~~
OhSoHumble
I think he was being sarcastic.

------
pinaceae
My team is working on an big application with 100k+ users, worldwide,
generating a couple hundred mill in revenue/year. Native apps on multiple
mobile platforms, heavy enterprise stuff.

Tried it without stand-ups - doesn't work.

Once you need to coordinate heavily, care about speed and quality at the same
time, working in code bases others have written you try to align with others
as much as possible.

We do 2-3 stand-ups per week, depending on team preference. M-W-F or T-T.

It works, far less trial and error, far less issues found late in QA.

Daily is too much, that we learned. No structured stand-up at all doesn't work
either, humans are not disciplined enough across large teams.

YMMV.

------
supercoder
I like stand ups

~~~
dsjoerg
but whyy

