7 ms·

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 hel

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.

kelnos 7y ago
> 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).
- ElFitz 7y ago
  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...)
  - kelnos 7y ago
    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.)
oggadog 7y ago
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?
- mcv 7y ago
  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.
  - Torwald 7y ago
    > * 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.
brightball 7y ago
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.
mcv 7y ago
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.
- DougBTX 7y ago
  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.
  - solidasparagus 7y ago
    I'm curious, why were they draining?
    - vfc1 7y ago
      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.
      - 7y ago
m0nty 7y ago
> 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).
- gbersac 7y ago
  it's so true it hurts
vfc1 7y ago
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.
- BigJono 7y ago
  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.
- jonbronson 7y ago
  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.
- zamalek 7y ago
  > 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.
debt 7y ago
“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.
jaredklewis 7y ago
> 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.
- mywittyname 7y ago
  > 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."

kelnos 7y ago

> 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).

ElFitz 7y ago
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...)
- kelnos 7y ago
  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.)

oggadog 7y ago

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?

mcv 7y ago
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.
- Torwald 7y ago
  > * 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.

brightball 7y ago

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.

mcv 7y ago

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.

DougBTX 7y ago
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.
- solidasparagus 7y ago
  I'm curious, why were they draining?
  - vfc1 7y ago
    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.
    - 7y ago

m0nty 7y ago

> 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).

gbersac 7y ago
it's so true it hurts

vfc1 7y ago

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.

BigJono 7y ago
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.
jonbronson 7y ago
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.
zamalek 7y ago
> 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.

debt 7y ago

“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.

jaredklewis 7y ago

> 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.

mywittyname 7y ago
> 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."