Live data from Hacker News

You don’t need standups

medium.com

131–140 of 341 posts

Re: You don’t need standups

#131
post #80
post #69

Earlier quoted context omitted.

That's useless because everybody else tunes out. Nobody cares what debugging methods you tried on some project they've never touched. If you need help you can just ask somebody.

1. Isn't the standup usually the place you're told to initially ask for that help? 2. Aren't most people, at least the developers/designers in the same standup, supposed to be working on the same project?

Don't wait until the standup to ask for help if you don't have to.

I'm also confused why OP is having standup eith people who havent even heard of the project he's working on. Doesn't sound like he's working on the same product as the other developers.

Re: You don’t need standups

#132

One thing I don't like about standups is that they can create a false sense of either blockage or someone being ineffective at their job. For instance, there have been many times where I've worked on a task or a set or related tasks for weeks or months, simply because the tasks required a lot of forethought and careful planning. There were times I somewhat dreaded standups because I knew that I'd say that I'm doing t…

Whether standups are useless or not depends on the dynamics of the team. With the team I'm currently working in there are no standups, all communication is async and everyone knows what everyone else is working on. If there's a problem, holler in chat, or discuss IRL. There's also the project board where anyone can just hop in to see progress. There is a trust in each other in my team, which is not something I can say for other teams I've been with.

The whole agile methodology shouldn't be taken as is. Standups, sprint planning, retro etc all can be ala-carted with modifications depending on what type of team you're in and the people in it. The ideal scenario is that the team is a well-oiled machine, much like a precision, well built watch. No standups or meetings that force context switches and interruptions.

Adapt to the team. Do away with unnecessary processes. Just because standups are done everywhere doesn't mean you have to do it just for the sake of 'following the process'. It also doesn't mean you should do away with it, if you have a team that's new, or if there's a lack of communication or trust in each other. Isn't the point of agile, to be agile in everything that we do, including the agile processes themselves?

Re: You don’t need standups

#133

One thing I don't like about standups is that they can create a false sense of either blockage or someone being ineffective at their job. For instance, there have been many times where I've worked on a task or a set or related tasks for weeks or months, simply because the tasks required a lot of forethought and careful planning. There were times I somewhat dreaded standups because I knew that I'd say that I'm doing t…

I have other issues with standups, but if your concern is "I don't look productive and I don't want to talk about what I'm doing" not having standups isn't going to make you look more productive. If you're working heads-down for weeks or months without standups, people are still likely to wonder if you're stuck/ineffective/blocked if you're not communicating in more detail than "it's still in progress."

I think the desire is more to have goals and work towards those. If you don't have daily goals, then having a daily standup is going to be pointless.

That is, if I am working for weeks or months without making visible progress, but I have successfully delivered the last X things on time, why are you worried about what I look like?

So, yes, people should grow into longer timelines that they can appear to be slacking off. I expect the tasks we've given the newest intern, as an example, to be something that can show daily progress. In large, because it will likely need daily coaching. As you get on the larger projects, though, asking me to break everything down to daily chunks is itself a chore that may add significantly to effort.

Worse, it encourages people to fall for the sunken costs fallacy. If you burned down all of that effort, many folks are hesitant to take any of it back. If I haven't let you know about the small progress I made on the last experiment I did, then I am as likely to abandon the path and try something else if I am confident it will be better.

Re: You don’t need standups

#134
This should really be taken as an example of a team that got rid of standups and did well. Every team is different and without prior knowledge of the team featured in this article, it's hard to judge if this advice is any useful to me. I would've preferred if the tone was more like "Why we didn't need standups" not "You don't need standups".

Re: You don’t need standups

#135
post #80
post #69

Earlier quoted context omitted.

That's useless because everybody else tunes out. Nobody cares what debugging methods you tried on some project they've never touched. If you need help you can just ask somebody.

1. Isn't the standup usually the place you're told to initially ask for that help? 2. Aren't most people, at least the developers/designers in the same standup, supposed to be working on the same project?

#2 never happened at any job I've had. It was always the entire team and we all had different projects. Sometimes entirely different applications.

Re: You don’t need standups

#136
post #94

Earlier quoted context omitted.

I famously got outraged at my team the day after our planning meetings + interviews the whole team was on. "Yesterday we had meetings" because while that's helpful in retro finding out where time went; it doesn't update or encourage more thought on the current work. I pushed my team to think about things that others would ask questions about and how it affected their work.

But they likely haven't actually started anything. I think that's the worst part about standups is they require everyone to get up and say something. If you've got nothing to say, then you end up saying idiotic stuff like "yesterday was meetings". (I do also think that having everyone take a turn at speaking is one of the good things about them, because otherwise it's really easy for one or two people to take the who…

[deleted]

Re: You don’t need standups

#137
post #46

Earlier quoted context omitted.

Standup just before lunch might work better. That’s my experience.

It works very poorly in practice, in my experience. You interrupt people 2-4 hours into their work, which is highly disruptive for those who get the most done in the morning. Often discussions run on past many peoples' lunch time, which can make people cranky and occasionally leads to tense exchanges which might have been more amicable if people weren't hangry. You wind up with people melding the work they did during…

If you're not keeping the daily scrum shorter than 15 minutes then that's in and of itself a problem that will make people annoyed and disrupted.

Re: You don’t need standups

#138

One thing I don't like about standups is that they can create a false sense of either blockage or someone being ineffective at their job. For instance, there have been many times where I've worked on a task or a set or related tasks for weeks or months, simply because the tasks required a lot of forethought and careful planning. There were times I somewhat dreaded standups because I knew that I'd say that I'm doing t…

Then that is a project that should not use Agile in my opinion.

Re: You don’t need standups

#139
One thing that the standup helped me was getting blocked by a senior developer.He would never answer my questions normally. But once we started with scrum and daily standups, there was that I am blocked because of something that can be answered by another developer within 15 minutes. Standups make a team working.

Re: You don’t need standups

#140
post #129

The entire concept of a sprint to me always felt wrong. Development work can't be split up into time slices. And trying to divvy up tasks based on an estimate of how long it'll take to complete each one is just a waste of time. I remember being in a standup, being told to bump a high-priority task into the next sprint and complete a couple low-priority tasks instead because I already had too many points assigned to m…

> We estimated the amount of time each task would take, assigned it points based on that, and we'd fill our task list in such a way to try to make the estimation close 40 hours of work. The concept of story points was invented as an attempt to solve the problem of developers reliably estimating the amount of time a given task will take. If you're directly equating story points to time then you're doing it wrong.

And yet, story points are used to estimate how much work a team can get done in a sprint, which is a time measurement... and they are used to track velocity, which is used by management to figure out when a project might be completed (also a measurement of time).

"Oh, story points are just about the complexity" Oh really? Why does complexity matter, if not to function as an indicator of how long something might take to finish?

Anyone who is telling you that story points aren't directly related to time estimation is either confused, or lying.

Post reply on HN