Live data from Hacker News

An Alternative to Stand-up Meetings

weblog.alexgodin.com

41–50 of 51 posts

Re: An Alternative to Stand-up Meetings

#41

I think people make a mistake when they assume that the stand-up is about an exchange of data. It's not. It's a social construct. Technology development, especially in a team, is a social activity. We need to create social rituals for it to work at maximum efficiency. The "bugs" he sees in the process, "synchronous, everyone needs to be in the room (or on the phone), and often after the meeting much of the content is…

I say it over and over: This is not a status meeting, this is a communication meeting. What isn't a blocker for you, might be a blocker for someone else.

Re: An Alternative to Stand-up Meetings

#42

I think people make a mistake when they assume that the stand-up is about an exchange of data. It's not. It's a social construct. Technology development, especially in a team, is a social activity. We need to create social rituals for it to work at maximum efficiency. The "bugs" he sees in the process, "synchronous, everyone needs to be in the room (or on the phone), and often after the meeting much of the content is…

Thanks for putting into words and explaining so eloquently why stand-ups are the most unpleasant 5-10 minutes of my working day.

Re: An Alternative to Stand-up Meetings

#43
post #8

Earlier quoted context omitted.

> but that everyone knows everyone else heard it. How about simply having a company policy that everyone should MVCC their decisions based on received email "transactions"? I.e., if someone sends out an email, then everyone else MUST (in the RFC sense of MUST) read it and digest it before making any new decisions. It still operates asynchronously--you can finish whatever you were head-down working on before checking…

The problem to correct itself is all this bullshit TPS reporting hidden behind fancy new buzzwords and "methodologies". My rule is: if something affects my work, put it in my TODO list. If I am a Devops engineer, reading emails or standing up in a circle (jerk) pretending to listen carefully and understand what designer X, mobile developer Y and product manager Z did the day before or plan to do today is a waste of m…

No it's not. Because frequently, the things which are blocking you could be easily fixed by them changing something simple in their workflow, and vice versa.

Even just a heads up that something important is coming down the line can save you hours or days of work "Oh, I thought you were cc'ed in on that email..."

Re: An Alternative to Stand-up Meetings

#44
post #8

Earlier quoted context omitted.

> but that everyone knows everyone else heard it. How about simply having a company policy that everyone should MVCC their decisions based on received email "transactions"? I.e., if someone sends out an email, then everyone else MUST (in the RFC sense of MUST) read it and digest it before making any new decisions. It still operates asynchronously--you can finish whatever you were head-down working on before checking…

The problem to correct itself is all this bullshit TPS reporting hidden behind fancy new buzzwords and "methodologies". My rule is: if something affects my work, put it in my TODO list. If I am a Devops engineer, reading emails or standing up in a circle (jerk) pretending to listen carefully and understand what designer X, mobile developer Y and product manager Z did the day before or plan to do today is a waste of m…

Why are you in a stand up with people whose work doesn't affect yours? That's fundamentally not right. I think you're ascribing problems to daily standups that are more to do with your specific organisation.

Re: An Alternative to Stand-up Meetings

#45

I think people make a mistake when they assume that the stand-up is about an exchange of data. It's not. It's a social construct. Technology development, especially in a team, is a social activity. We need to create social rituals for it to work at maximum efficiency. The "bugs" he sees in the process, "synchronous, everyone needs to be in the room (or on the phone), and often after the meeting much of the content is…

The other thing that a lot of people forget is that a stand up is supposed to be informal.

If you're leaving a paper trail that management can go back through (even in theory), then it will get sanitised, and people will try and make themselves look good. The further you get from reality, the more value your "stand ups" will lose.

There's a good reason for the "pigs and chickens" analogy.

Re: An Alternative to Stand-up Meetings

#46

I think people make a mistake when they assume that the stand-up is about an exchange of data. It's not. It's a social construct. Technology development, especially in a team, is a social activity. We need to create social rituals for it to work at maximum efficiency. The "bugs" he sees in the process, "synchronous, everyone needs to be in the room (or on the phone), and often after the meeting much of the content is…

Thanks for putting into words and explaining so eloquently why stand-ups are the most unpleasant 5-10 minutes of my working day.

Thanks for not adding anything meaningful to the conversation.

Re: An Alternative to Stand-up Meetings

#47

Now on the one hand, we do mail-ins as well whenever someone can't make it to the stand-up, especially since any team member can work from home whenever they like. Plus our starting time is loosely defined as "let's all try to be there around 10-ish", so some people are already in the flow since 8:30 by the time the last team member shows up. However, every time someone proclaims to have found a better alternative fo…

"One look, one gesture"? This is engineering, not a fucking love story. Ordinary English should be sufficient to communicate status information.

Re: An Alternative to Stand-up Meetings

#48
post #10

No, no, and no. A 15-minute standing meeting is much more efficient. Mandating daily email check-ins means developer time would be wasted writing these emails, and everyone's time is then wasted reading these emails and then participating in the ensuing off-topic discussion threads spawned from each email. A scrum-master's job is remove impediments, and thereby allowing developers to concentrate on development. Manda…

I can read faster than you can speak. I can probably even write faster than I can speak. And most importantly, I can defer both activities to a time when I'm not focusing on something. It's standups that are the impediment.

Re: An Alternative to Stand-up Meetings

#49
post #8

I dunno... I feel like if I'm totally honest, there's a good chance I would wind up just ignoring 90% of those e-mails, or at least not reading them carefully enough. For me, I feel like the benefit of a stand-up is exactly that it forces everyone to pay attention and meet for 5 min, not just so that everything important gets communicated, but that everyone knows everyone else heard it. And people can ask important q…

> but that everyone knows everyone else heard it. How about simply having a company policy that everyone should MVCC their decisions based on received email "transactions"? I.e., if someone sends out an email, then everyone else MUST (in the RFC sense of MUST) read it and digest it before making any new decisions. It still operates asynchronously--you can finish whatever you were head-down working on before checking…

Now you have 50 status emails and 100 responses to those emails (and 50 responses to those responses...) that you MUST!!1! read and digest each day.

Plus other people have already made (bad) decisions and started working on stuff that (negatively) affects you because you were busy "head-down working".

These are the problems that stand ups are supposed to help fix.

Re: An Alternative to Stand-up Meetings

#50
post #8

Earlier quoted context omitted.

> but that everyone knows everyone else heard it. How about simply having a company policy that everyone should MVCC their decisions based on received email "transactions"? I.e., if someone sends out an email, then everyone else MUST (in the RFC sense of MUST) read it and digest it before making any new decisions. It still operates asynchronously--you can finish whatever you were head-down working on before checking…

Now you have 50 status emails and 100 responses to those emails (and 50 responses to those responses...) that you MUST!!1! read and digest each day. Plus other people have already made (bad) decisions and started working on stuff that (negatively) affects you because you were busy "head-down working". These are the problems that stand ups are supposed to help fix.

It sounds like the problem there is that you have a "team" with 50 people on it. You don't need to know things that don't affect you; if everything affects you, your organization doesn't know how to compartmentalize its architecture.
Post reply on HN