Hacker News new | past | comments | ask | show | jobs | submit login

I am definitely a "moody diva", I think because daily standup in particular forces me to admit more failures than I would have to otherwise (you need to fail before you succeed). And it's ultimately pointless and more stressing for everyone, because lot of these failures get resolved the next day.

In some sense, standup is a nocebo, a mood killer for me. I am there, in the morning, ready for work, my mind firing up, geared towards working the problem, but no, I have talk and listen about something unrelated. It's like going to a movie and having to suffer the trailers for other movies first.

(There was also this funny psychological research that showed that when you tell someone you will do something, you're less likely (less motivated) to do it. Not sure if true, but if it is then standups alone have caused billions of loses in productivity.)

In any case, I think the discussion about individual productivity is somewhat sidetracking the core issues. What I wrote applies to the whole team as well. In my experience, the best design decisions come from individuals working alone, understanding the problem, and then these design decisions are vetted (and possibly changed) by everyone in an open discussion. This cycle can happen on almost any timescale, depending on the nature of the problem. So one doesn't need to be in an ivory tower for this to work.

Timeboxing as such is not a bad idea. But I think conflating it with "being done" is just wrong.




Some standups, I feel like I'm back in primary school doing show and tell, as I get regaled with tales of whatever meeting someone had (even better when several people feel the need to bring up the meeting that literally the whole team attended), or their progress on a completely unrelated project/feature which may as well have been what they had for dinner last night, for all relevance it has to me.

They do have their benefits though, especially when well run. A team member may encounter something they're having difficulty with that another developer has encountered and solved in the past. You might want to share a problem you encountered or findings that are relevant to others.

I suppose that most of those things could just be done as a slack message. Sometimes I feel like a meeting helps ideas flow better though. There's been occasions where having an actual verbal conversation with the team has yielded better results than a slack conversation would've.

Either way, I've never had a huge issue with them, as long as standup is the start of my working day and not like 10 AM or something where I'm going to get interrupted.


> A team member may encounter something they're having difficulty with that another developer has encountered and solved in the past. You might want to share a problem you encountered or findings that are relevant to others.

IME this has been the biggest boon of standups. If they are kept short, and further conversation is done outside the meeting, they are a good way of matching your problems to other people on your team who may have a solution.

> Sometimes I feel like a meeting helps ideas flow better though.

I generally prefer when protracted conversation/problem solving is taken up between the concerned parties after the meeting, as otherwise the meeting drags on for everyone else who doesn't really need to know about your particular issue. But I do definitely agree with your assessment that "actual verbal conversation[s]" are better for me with regard to figuring a problem out.


> and then these design decisions are vetted (and possibly changed) by everyone in an open discussion

But don’t you dare try to have an open discussion at a stand up meeting. The moment a useful discussion starts the scrum “master” will tell you to schedule a separate meeting to discuss it. Honestly, that just kills the flow of communication. I have never scheduled a separate meeting to continue the discussion. We just end standup, go back to our desks, and don’t talk to anyone.


The moment a useful discussion starts the scrum “master” will tell you to schedule a separate meeting to discuss it.

Have you considered that if this didn't happen, it would be one of your co-workers on this thread, instead of you, and they'd be complaining that:

"Our scrum standups are supposed to be 15 minutes long, but they always take an hour or more, because people start going down some rabbit hole that doesn't concern half the team, and the scrum master won't politely interrupt and ask them to schedule a separate meeting. So much time has been wasted by this that it's unbelievable."

I have never scheduled a separate meeting to continue the discussion.

Why not?


If a useful discussion happens during a standup the people discussing can just leave and let the others continue the standup without them. There is no point in being strict with these things.


Agreed. I was just curious about why, specifically, the parent poster never schedules follow-ups. If the discussion in question was actually valuable, it seems like they would want to pick it up later (or use your approach of just forking off immediately. I look at those two things are being approximately equivalent).


> can just leave and let the others continue

That can be hard -- many / some people would be worried it'd be impolite to leave and in a way say "the things you're talking about aren't interesting to me".

And they'll stay and feel frustrated, in silence.


That sounds overly harsh. What we do in our team is "postpone" those discussions. When people have went through their updates, anyone who wants to stay is free to do so and can continue that discussion, usually in the same channel. This way you're not forcing people who _don't_ want to listen to that discussion to sit through it twiddling their thumbs - best of both worlds :).


This. When I structured the standups for our own team, I budgeted 15 minutes for updates and 15 minutes for open conversation.

The result has worked almost exactly as intended: there's breathing room to discuss issues or ideas that come up in the course of conversation, but discipline around keeping those conversations brief enough to stay on the rails.

IMO at previous companies getting told "this isn't the time for that discussion" really frustrated me. As the OP stated, these conversations never happened, and it's healthier to allow some time and space for people to talk off-script when they're all meeting together.


Would moving the standup to sometime where you are naturally interrupted, e.g. just before or after lunch, work better for you or is it the nature of the standup itself that's the problem?

1) Communicating is part of the job 2) Don't think about it in terms of 'failure'. You're just doing work. Sometimes the route is direct, sometimes it's not. 3) 'Time boxing' really has to be done, because products are not made in a vacuum. Time is money and it's a huge constraint. So everything really does have to be boxed up and parameterized by 'time' in the most reasonable means possible that doesn't screw everything up.


1) They were disputing scrums, not necessarily communication. 2) It's hard to not think of something as failure, if it's treated as failure, which is often the case. This is like telling someone who's being mistreated in a relationship to not think of it as abuse, just think of it as your way of life. 3) Time boxing may be important if a number of different types of schedule conflicts may arise, but I think it can place an undue importance on the measurability of how something gets done, often at the cost of it actually getting done well.


1) Scrums are literally communicating. 2) Just because someone feels there is a failure does not mean other people perceive it that way. If you describe it as a step towards the finish, then it is. 3) Time-boxing is inevitable. If there is a side-step due to some other issue, then you describe why the time boxes must be moved.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: