Live data from Hacker News

You don’t need standups

medium.com

121–130 of 341 posts

Re: You don’t need standups

#121
Here's a thought experiment, and a challenge: When was the last time you learned something really important at a standup meeting that you wouldn't have learned otherwise, either by talking to someone directly or in some form of asynchronous communication?

I bet it was a while ago, if you can even think of anything specific.

Standups, in my experience, are a net negative, in that there is a cost, but rarely a benefit. I almost never get anything useful from them. I don't need to know that the product owner is in meetings all day. That's almost every day. I don't need to know what every single other developer is doing every single day. If I have a general idea of what the team is doing that's usually good enough. If I am blocked on something, how is that useful for you to know? If there's anything you can do about it, or need to communicate to somebody else, I've probably already talked to you. And if I haven't talked to you, it's almost certainly irrelevant to you.

Challenge: For the next week, make a note (actually write it down on paper) of something useful and actionable you learned at a standup meeting, and see how many times that happens. Then compare the cost of the time spent in standups to the number of times it was useful.

Re: You don’t need standups

#122
post #63

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…

"working on bugs" is not a great update, it's opaque and doesn't help your team or your leader get a picture of what you're struggling with. "I tried this and this and measured this latency from the application and suspect it's a race condition, I checked this code and feel like I'm on the right track, and if someone wants to take a second set of eyes on my bug I would appreciate it" is a much much better update. Sta…

You can learn coping strategies to get better at it though.

Re: You don’t need standups

#123

All of this is even worse with a distributed team. Don't get me started on what happens when contractors enter the picture. Edit: and so-called development managers!

I've had some truly great development managers, and some really mediocre ones. It's helpful to have a technical manager that can shield you from certain issues while still understanding your needs enough to actually meet them.

Re: You don’t need standups

#124
post #33

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…

Besides that, I hate that they took me out of rhytm of work. If a standup is at 10am, and I arrive at 9am to do dev work, there is very little I can do before being interrupted - I need at least 2-4h of interrupted time to do some good work.

That's why you should do them at the end of the day as we did of my first very successful Agile project - presented at the IIIE I believe after we finished.

Though that was the full on clean room high level sponsor route, collocated with the customer.

Re: You don’t need standups

#125

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

Re: You don’t need standups

#126

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…

Why are you estimating things in hours? Why is management tracking the amount of story points every developer completes in a sprint? Why are you not working on the highest prio stuff in the sprint? Of course sprints look useless if you're doing them like that. Do you even have a clear sprint goal you're working towards?

> Why are you estimating things in hours?

Because anything else is completely arbitrary. I mean, we ARE measuring things in "points", but with the understanding that 1 point ~ 1 hour of work.

> Why is management tracking the amount of story points every developer completes in a sprint?

Because they want metrics on productivity. I don't entirely blame them.

> Why are you not working on the highest prio stuff in the sprint?

As mentioned, because management really wanted to see us complete 40 hours of work every week, and getting close to 40 hours done per week was more important than priorities. If something couldn't be finished before the end of the sprint, they thought it was better to push it to the next sprint, rather than leave something incomplete at the end of a sprint.

> Of course sprints look useless if you're doing them like that. Do you even have a clear sprint goal you're working towards?

I was on a QA team writing test code. I specifically was writing security tests, while others wrote functionality or stability tests. Each sprint goal was effectively just "Write these tests".

Re: You don’t need standups

#127

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…

Why are you estimating things in hours? Why is management tracking the amount of story points every developer completes in a sprint? Why are you not working on the highest prio stuff in the sprint? Of course sprints look useless if you're doing them like that. Do you even have a clear sprint goal you're working towards?

People always say not to estimate in hours and instead to estimate in "points", but at the same time teams tend to plan around how many points they're taking into a sprint. If you have 40 points but usually take only 30, you'll be asked to bump something out.

And once you agree on a number of points to do in 2 weeks, it's not rocket science to figure out an estimated number of hours per point.

Re: You don’t need standups

#128

Earlier quoted context omitted.

>Because they show common misunderstandings about Agile I agree with most of what you're saying. I've found this to be the biggest barrier to the process actually working. People don't understand the purpose of what is being achieved with X meeting/process and so will actively try to subvert it. Sometimes as engineers we're too smart for our own good, and sometimes we don't listen to what we're being told. I went thr…

I'm Old Expert Programmer Dude now, so I get to tell stories. 1. Worked with a team of outside experts once. We were brought in to stand up an internal team of coaches. The first week there, the four of us got together. I asked "Do we want to do standups?" Another coach said nope, we're professionals! What do we need standups for? The rest of us met every morning for breakfast. No standing up, no meeting. But we knew…

>see a pattern here?

Yes, the pattern is arrogance.

>And when it works, it doesn't feel like anything has happened

Exactly, which is why it's so hard to keep people on board when all is going well. The meetings start seeming like a waste of time and then you end up falling into cyclic relearning traps.

Good chat though, I'm sure most people who have been SMs will have similar stories.

Re: You don’t need standups

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

Re: You don’t need standups

#130
post #81

Standups always felt to me that they had a core negative message to developers. It's not about communication at all. Its about control, its about saying: We don't trust you. We are going to check on you to see what you are doing, every single day, because you are not a responsible adult and need constant surveillance. Its also about putting constant psychological pressure on developers, to make sure they complete the…

You might be right, but I think you shouldn't be focusing your resentment at standups themselves, you should be focusing on the managerial or corporate culture.

I've worked in places that did standups and places that didn't, and found that the lack of trust / constant surveillance / psychological pressure can be there regardless of whether standups are used.

What does change, though, is that with standups, a manager has the reassurance that they are checking up on their developers every day, and the developers in return get the reassurance that their boss is only going to interrupt them once per day at a fixed time (or at least there's a better chance this is how it works out).

I see "agile" as being a set of compromises and helpful cultural patterns which were designed by taking into account all the weird cognitive biases that brains get forced into by the group dynamics of working in a team on a project.

Post reply on HN