Hacker News Reader

Comment by BigJ1211 | Hacker News Reader

Don't agree with this assessment at all, we do stand-ups and it rarely takes more than 5 minutes. It help immensely with production as your colleagues often help keep things from falling through the cracks. (I.e. someone forgets something). Or they might be able to help you out, or further along because they've done something similar. When they do, you don't do it during the stand-up to not disrupt that.

Overal I don't think it's disruptive at all to do a short stand-up, constant nagging however is very disruptive. That person that just walks in or starts spamming you on slack takes more time altogether per instance than a single stand-up does. It takes you out of your process, you then have to pick that up again. If you're working on something complex that can mean it takes an additional 10 minutes before you're back on track. That's the kind of disruption stand-ups can help prevent.

This of course only works if you actually stick to what the stand-up is meant for.

View on HN

It's a bad article. Standups shouldn't be disruptive at all. Just a couple of minutes to get some idea of what everybody is working on. Standups are in my experience much more effective at signalling blocking issues than slack. Nobody is going to spend their day checking what other people are doing on Jira, so the standup is the perfect time to inform everybody efficiently.

If any issues come up, you can discuss them immediately after the standup.

Long meetings are terrible, but short meetings are great. That's the whole idea behind the standup. If a couple of minutes per day kills your velocity, as the article claims, I wonder what else you're doing during the rest of the day. It only has a measurable impact on your velocity if you're only a working an hour per day. And even then I'd guess it's useful to have a quick refresher about what you're working on.

Perhaps they shouldn't be disruptive, but in practice they were a daily drain. I'd be happy to never go to one again. Now every day I can come in to the office, can grab a coffee and get to work. Far more relaxing.

I'm curious, why were they draining?

Because you have to think upfront what are you going to say. You might me interrogated in front of everyone else about something that you are doing, and will have to come up with an answer on the spot.

This is obviously stressful, and psychologically pressures you to try to finish the task ASAP the day before, so that you can come up to the meeting and just say its done.

Which is the real actual benefit of the standup, and why managers keep doing it, despite they are obviously not needed and in most cases a waste of time.

The standup keeps everyone on their heels and feeling like their every breath is monitored and accounted for.

If you are being interrogated to the extent that you have to plan what you are going to say, the standup is being run poorly IMO.

Everyone has to spend at least some time thinking ahead of time what they are going to say, and you probably do too.

Its the perception of yourself and your work from the eyes of the group that is at stake here, it's important and most people usually don't just improvise it.

Many times people have notes of what they want to say, which involves preparation, attention and energy put into it that would better be directed elsewhere.

I don't know, on a healthy team you should feel very comfortable giving an update on your work without having to prepare.

I've prepared for standup when I was new to a team, but it should pretty quickly get to the point where you don't need that. At least for my experiences, it's not like standup is a major factor in how teammates think of you - that comes from working together with people.

I don't. Often it's "What was I working on again? Oh yeah, that one issue. And I reviewed some code. The thing I'm working on I hope to finish today, maybe tomorrow. That's it. Oh wait, I also deployed a thing."

It requires very little thought.

> Its the perception of yourself and your work from the eyes of the group that is at stake here

If your teams have so little trust in each other that you have to do all this preparation for a standup, then there are already much larger issues.

That's what happens when the PM (or other deadline-obsessed entity) is in charge though.

because they're unnecessary. I legitimately lose an hour a day due to them. I've started coming in late so I slide immediately into the daily standup because otherwise I fart around for the first 30-45 minutes until the standup starts.

There's just no deep work that can be done during that time, and that's every day.

I agree, that happens and it's really bad. When to hold standup is definitely an important question. I like first thing when people get in or two hours after everyone gets in.

You can't put 10 people in a room for a meeting for just a couple of minutes, that does not exist. The time people spend before the meeting not working just chatting around waiting, the natural inertia of the group it takes time to get everyone in a room.

Count the whole overhead time, from the moment people stop working normally waiting for the meeting, till the moment people come back to their seats, add up the extra coffee pause that people take afterwards that people would not usually take.

You are looking on average, at easily 15 to 20 minutes per person minimum a day, probably more.

Even so, 15 to 20 minutes on a whole day is nothing. It's less than what you lose on coffee or toilet breaks.

20 minutes is a lot of time, add that and at the end of the week you got around 2 hours, that's half a morning per week and close to a whole 8h day of work per month just on the time for standups.

It's not just the time itself though, it's the interruption that prevents you from starting longer tasks effectively.

Can't really account for that, work is not only about summing up minutes on a time tracking tool. There is rythm, there is acceleration, there is a productive state and there is deceleration.

Standups disrupt all that without any real benefit, other than serving as a daily reminder that you better hurry up with what you are doing - which most people don't need.

20 minutes across my team of 12 is not nothing, it's 4 man hours. When I see it communicated in that manner, the sheer pointlessness of these daily meetings is very easy for me to identify.

> Standups shouldn't be disruptive at all. Just a couple of minutes to get some idea of what everybody is working on.

That's disruptive!

> Standups are in my experience much more effective at signalling blocking issues than slack.

If you are using Slack, you have already lost the battle for productivity.

> If a couple of minutes per day kills your velocity, as the article claims, I wonder what else you're doing during the rest of the day.

Literally any interruption destroys your focus. A pending appointment destroys your focus. If you use Slack or E-Mail notifications, people never even attain focus, so in that sense it's not a loss.

> And even then I'd guess it's useful to have a quick refresher about what you're working on.

To a first approximation, nobody cares what you're working on. Nobody should care what you're working on. If your developers need to constantly communicate with each other, something is likely very wrong with the way you split up your work.

Daily standups pre-suppose that there's always stuff to communicate and that everyone is always involved, but only once a day and only briefly. This is complete nonsense. You need to be able to adapt to the situation. You need a meeting? Have a meeting with whoever is concerned. Have a follow-up meeting. Take your time and focus on the issue, then nobody will even feel like time is being wasted.

This sounds like an argument for having a single stand-up meeting instead of communication through slack and email spread throughout the day. It keeps the disruptions concentrated in a single, predictable moment.

> "To a first approximation, nobody cares what you're working on. Nobody should care what you're working on."

I care quite a lot what the people in my team are working on. Otherwise why are we even a team?

If you're not in a team, obviously things are different.

> "If your developers need to constantly communicate with each other, something is likely very wrong with the way you split up your work."

It's the opposite: if developers are not communicating, they're probably not cooperating with each other, which means something is very wrong.

> This sounds like an argument for having a single stand-up meeting instead of communication through slack and email spread throughout the day.

It's an argument for having meetings when you need them, with whoever you need them with, with no particular schedule or routine attached.

> I care quite a lot what the people in my team are working on.

Do you really? Or do you just want to signal that?

> Otherwise why are we even a team?

You are on a team because that's the unit of organization above the individual.

> It's the opposite: if developers are not communicating, they're probably not cooperating with each other, which means something is very wrong.

If developers need to cooperate, you have a problem that you should avoid at great cost. Of course, sometimes cooperation is unavoidable, but it's not a good thing in and of itself. Don't let anyone tell you otherwise. Aim to split up your work to require minimal cooperation. This may sound like unconventional advice, but anyone with enough experience managing developers will likely agree.

This seems overblown. Yes we all get interrupted - lunch, phone calls/texts, even the end of the workday are interruptions. To single out 'standup' as a particularly disruptive interruption may be exaggeration.

Of course, some interruptions like lunch or the end of the day are unavoidable.

Phone calls and texts? Don't let your developers do them.

> To single out 'standup' as a particularly disruptive interruption may be exaggeration.

It isn't an exaggeration, because a standup is also a pending appointment and a mini-presentation. A lot of developer types actually get stressed out about this, no matter how small.

Similar thing with responding to an e-mail. It's insane how much time some people spend on just a one line reply.

Just minimize these things, don't make them part of your routine for routine's sake.

If my options are a 15 minute standup vs. not being able to respond texts for the entire day, I prefer the standup.

It sounds like you and your coworkers are failing to use your tools, and falling back to having a periodic meeting instead of fixing your process.

>Standups are in my experience much more effective at signalling blocking issues than slack.

Your messaging tool is not good enough to communicate urgency? You cannot send a message and say "this is urgent" and have somebody read it and respond in a timely manner? You would have better luck waiting until the next standup meeting?

>Nobody is going to spend their day checking what other people are doing on Jira

Your primary work tracking tool is not good enough to allow people to see who is working on what, and what the status of that work is? You can't get an overview of what is being worked on? You can't check on a specific issue to see how far along it is?

Here's how it works when you use your tools:

1. You have an urgent issue. You message the involved parties. Your message should communicate the urgency of the issue. They read it and respond / take action within an appropriate amount of time.

2. You want to know what your team is working on. You look at your issue tracker to see what everyone is working on. If you are curious about the status of any work in particular, you look at the details for that work. If there is insufficient information about its progress, you send the assignee a message (see #1).

> Your primary work tracking tool is not good enough to allow people to see who is working on what, and what the status of that work is? You can't get an overview of what is being worked on? You can't check on a specific issue to see how far along it is?

In my experience most people don’t regularly post summaries of their progress on their ticket. Even getting certain people to update their ticket descriptions at all (to add test instructions or to reflect that they decided to do something other than originally described) usually requires reminders.

This may depend on team culture but in my experience a lot of people just aren’t written communicators.

Or communicators at all. It's like pulling teeth to get some of them to expand on "oh, it's blocked, I have to talk to Bob"

We're all professionals - we can learn new skills when they're high-value (like updating tickets with written communication)

I don't like the sentiment that developers doing things out of their comfort zone (like using JIRA) is unreasonable. Just get over it and be a professional.

That said, it's on others to motivate the use of such tools. It's easier to get buy-in when everyone understands the value.

It's not a bad article if it reflects the reality a considerable number of people face with this kind of cargo cult methodology.

A five minute meeting is not five minutes out of your day. Any scheduled interruption takes at least thirty minutes, probably more like sixty, out of productive time, as a flat cost, over and above the actual time of the meeting. It's all the time that you don't start biting into something worth doing because you look at the clock, and say "Oh fuck, I've got this fucking standup meeting in 20 minutes - I can't even get started on this before that rolls around and interrupts me." And it it all the time afterwards where you have had a bunch of shit laid in your lap that you have to spend some time following up on and frigging around with before you can get back to the work you already had planned to do.

> Don't agree with this assessment at all, we do stand-ups and it rarely takes more than 5 minutes

I do agree with it, because everywhere I've worked that does a daily standup does it wrong, and I think OA is more about those organisations.

For many old-fashioned companies, "doing agile" means waterfall + standups. Apparently that's all you need to reap that sweet agile-y goodness. The guy running the meeting doesn't enforce any structure, doesn't stop people rambling on for 10 minutes, doesn't try in any way to note or act on the points people raise. It's just about micro-management and cargo-cult development.

I'm sure with the right company a standup is a very useful tool. But wherever I've worked, it's been all about micro-management and a fundamental misunderstanding of what I actually need to do dev work (usually: a quiet office, no interruptions and time).

it's so true it hurts

You are just counting literally the time the first person starts talking till the last person ends, and even then its going to be closer to 10 minutes.

If you add up the time people have stopped working while waiting for the meeting, the time you take to gather people to a room, wait for the last one to arrive, start, go back, it's been 20 minutes total, and when standups derail and people start talking a lot it goes over half an hour.

You need to count the total overhead time. I mean come on, 10 minutes before the standup you are not really working full steam, right? You know you are about to have a meeting, so you are chatting with colleagues and checking email instead of working on your main tasks. That time should count too.

It's not even about the time, either. I do my best work in the morning. Almost every morning on my last project went like this: Get into work, grab a glass of water, bring up my todo list, start polishing off the first item, make 5 minutes of really good progress and the bam, standup.

The comparison isn't between the benefits of a good standup and nothing, it's between a good standup and whatever productivity you lost by interrupting the entire team (same as any meeting). You need to make sure it's worth it.

What? Every engineering team I've been on has done standups at their office/desk/bullpen. It literally takes exactly the amount of time of talking. Then we sit back down and resume work. You don't have to make it a full blown meeting. In fact, you shouldn't.

> 10 minutes before the standup you are not really working full steam, right?

Some colleagues don't 'work' at all between getting to work and standup (opting for soft tasks like email).

Wasting 15 minutes for 5 people a day costs the company almost 6 man-weeks a year, or really a week per person. Providing that week as PTO/leave would probably result in tangible productivity improvements.

Yeah same here. Everywhere I've worked standups have been really beneficial and usually only last about 5 minutes. I think the issue here is maybe the team size and stand ups dragging on for too long?

I've been in teams where standups are short and to the point, and in teams where they drag on for way too long.

A few elements that I think contribute to long standups:

* A very large team (I've been in a marged team of 14 people once...)

* Getting too much into technical details: don't do that; have your technical discussions after the standup with only the relevant people

* People sharing their opinion (frustration) about blocking issues and that developing into a discussion. Again, leave it until after the standup.

When standups drag on for too long, it's time for the scrum master to step in and get people to keep it short.

> * People sharing their opinion (frustration) about blocking issues

IMHO that would be okay, if not beneficial.

>and that developing into a discussion.

That not so much.

Agreed. Keep them short and focused. We use ours to review new PRs for the day and new requests that have come in from other parts of the company, in addition to covering blockers.

The PRs cover the “what did you do?” questions while getting eyeballs reviewing the work and for larger PRs we will schedule something. Keeps things moving well.

The inbound requests reviews keep us from having to have backlog estimating meetings as often since we are keeping up with it as they arrive.

If the time isn’t useful, find a way to make it useful.

> That person that just walks in or starts spamming you on slack takes more time altogether per instance than a single stand-up does. It takes you out of your process, you then have to pick that up again.

Walks in? Yes. That should be discouraged always.

Spamming on Slack? If that is a problem, you're doing Slack wrong. It's an asynchronous method of communication. Don't be buried in it or feel the need to respond to every message as it comes in. Check it during natural breaks or stopping points.

If something actually is urgent and requires your immediate attention, then they can break the above rule and walk up to your desk (or call you if you're remote).

Some of my colleagues had a hard time with this. They would actually ask me to come to their desk whenever I had a question, and come to mine when I didn't answer fast enough (only after I had gotten them to understand I really preferred slack. Seems they never got the why though, despite making it very clear...)

Yep, there are some people who just don't get it, and it's hard to get them to. I find that most developers have a hard time even bringing up the issue with someone face-to-face, even though all it usually takes is: "Hey, just wanted to let you know, I really prefer having these sorts of exchanges over Slack. Otherwise I find it really disruptive to my day. Could we give that a try next time and see how it works out?" And you have to be willing to escalate if the behavior doesn't improve: "Listen, I asked if we could take care of these things over Slack, and I'd really appreciate it if you could accommodate me here." Then: "Hey, I know I keep bringing this up, but it's really important to me. I need to keep a lot of my day interruption-free in order to be productive. Please try harder to respect my time when coming to me for help."

It seems most developers aren't even comfortable with the first bit, let alone escalating things. Instead, most people just seethe and complain privately to other colleagues, and nothing changes. At the very least, the team's manager should be brought in to do a better job of protecting the everyone's time, and you'd think that would be easy for a developer to do, because it outsources any sort of confrontation. But it still often doesn't happen, for whatever reason. (Of course, if it's the manager who is the offender here, you're probably screwed if the diplomatic method fails.)

> This of course only works if you actually stick to what the stand-up is meant for.

This is my big problem with agile, scrum, and friends. It's like communism; it only works if you "do it correctly." Russia? China? Cuba? Yea, they didn't do it right, but if it's done right, it's really really great.

I have only ever read about agile and scrum being done correctly. Obviously, I'm just one person, and my experience is limited, but at every company have I ever worked at or consulted for, the practice of agile and scrum is very different than what I read about.

I have experienced the less than 10 minute standup maybe a dozen times ever. Not that there is usually much to talk about. "Yesterday I worked on on X. Today I will keep working on X."

But somehow enough people in one place just seems to create so much friction. There's always a tangent. A: "By the way, how long do you think until we finish X?" B: "I don't know. Kind of depends on Y and Z. I never did Y before." C: "Oh, I did Y before, it's easy, you'll have no difficulties" and on and on.

I can see two possibilities:

1) My experiences have been not been representative of the industry as a whole. On the whole, agile and scrum work well and are executed properly at most companies, but I've just had some bad luck.

2) My experiences are representative. In this case, agile/scrum is so difficult for the average company to pull off, that it's kind of a rare occurrence.

The fact that angst-ridden articles like this one are such a regular occurrence on HN kind of makes me suspect that it's #2, not #1.

I'm just an engineer, so project management is not my area of expertise, but my layman's opinion is that an actually good project management system should "fail gracefully," as it were. You shouldn't need a 1 in 1000 level PM to pull this stuff off.

> On the whole, agile and scrum work well and are executed properly at most companies, but I've just had some bad luck.

Not a chance -- your experience mirrors mine over the course of the six or so companies that I've worked for. It's definitely #2.

They all fail in very similar ways: story points become hours/days; stand-ups devolve from status updates to daily team discussions; the backlog becomes irrelevant because new stories are created for each sprint; and, in companies which report velocity to senior management, story-point inflation.

Also, I've noticed that Agile transformations always create Agile zealots within the organization which seem to act to quell dissent. I'm not sure why this is, maybe the transformations are tied to bonuses or something, but it's a universal thing. There's always somebody running around telling you that you're team is Doing It Wrong when you bring up any legitimate criticisms of the process.

See:

> It's like communism; it only works if you "do it correctly."

“It help immensely with production as your colleagues often help keep things from falling through the cracks.”

But your job as a developer is to not have this happen. It’s nothing something that would be a nice to have, you’re supposed to always keep your team informed about potential gaps. The standup is designed to catch gaps but really that should be something you should already be doing.

Reply on news.ycombinator.com