Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You don’t need standups

medium.com

Post reply on HN
Print view View original

81–90 of 341 posts

Re: You don’t need standups

#81

Post by vfc1 »

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 tasks as soon as possible, and move on to the next task in the list.

Even if developers know that some refactoring is absolutely needed or this production issue needs a closer look because something strange is going on, developers don't have the autonomy to just do what they know needs to be done.

Everything needs to be pre-approved by a non technical manager and assigned a JIRA or equivalent.

Looking back, to me its clear that I resented standups, they made me feel like I was being treated as an assembly line worker.

Re: You don’t need standups

#82

Post by some_account »

chomp wrote: post #63
ravenstine wrote: post #28

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…

What if I don't want a team mate to look at something I'm working on? What if I just want to focus on building, not explaining and sharing?

The current trend of "agile" is just another form of micro management. It's not good for the programmers at all, it's only good for product owners and team leads who are coordinating resources. Because it's micro management. We just call it something else now.

It forces developers to share every mistake they make, it makes them share if they are thinking incorrectly about something, it makes them easily replaceable.

Let's just stop pretending it's good for the programmers, alright?

Re: You don’t need standups

#83

Post by irrational »

I work on a team where 3/4 of the team are business people. Yet we have a stand up with the entire team everyday and everyone talks about what they are working on. How is hearing that you are talking to account X about something or just came back from conference Y applicable to the job I've been hired to do? Likewise when it comes to my turn to talk it often turns into "blah blah blah [giggle] I don't know what any of that means! computers!" from the business people. It's so useless.

Re: You don’t need standups

#84

Post by Benjammer »

chomp wrote: post #63
ravenstine wrote: post #28

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…

It feels like the article is trying to sell a _different paradigm_ and you are arguing why the individual steps won't work under the current paradigm...

Re: You don’t need standups

#85

Post by Benjammer »

DanielBMarkham wrote: post #79
idts wrote: post #42

Earlier quoted context omitted.

You describe a better way of doing standups than simply status reports, but I'm finding it hard to distil into a couple of sentences. Could you help me understand what a better standup would look like?

Talking about team communication in the abstract is difficult. I wrote a book about it. [1] The problem is that you are looking for the maximum amount of valuable communication with the minimum amount of overhead. That is almost impossible to reliably quantify, however, because each team develops their own communication and language style. This is the tension we face: outside folks who mean well want to standardize t…

Do you have any advice for someone in a senior IC role to actually get people setting the processes to shift their thinking from optimizing general metrics and making everything more homogenous, into a model where everything is contextualized (like your examples) and then we draw out higher-level patterns by analyzing the common traits that organically arise as a result of contextual solutions?

Re: You don’t need standups

#86

Post by lttlrck »

chomp wrote: post #78
ahelwer wrote: 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.

I think that's either a team culture issue, a management issue, or a business culture issue. Teams I've worked on have had no issue brainstorming ideas for a person who's stumped. Now, I'm not totally defending standups here, I've been on teams where daily standups are a stuffy formality, and they are miserable. I've also had the pleasure of being on teams where weekly standups were implemented, and they were an abso…

Are stand up meetings the correct venue for brainstorming?

Re: You don’t need standups

#87

Post by s73v3r_ »

DanielBMarkham wrote: post #31

I always upvote these things, not because they're right. Because they show common misunderstandings about Agile. Agile is so simple and easy that the development community continues to screw it up. It's important to understand how. According to the author, standups are something companies require developers to do to report about what they're doing. Many times they can take more than a half hour. That may be true, but…

I think most times, the individual developers are not the ones that choose to do Agile (or which flavor of Agile), and in many cases, they have no agency to change anything. So when you're in a situation with "hour long standups," you're not really able to do anything about it, due to the business people who are really in charge not wanting to change.

Re: You don’t need standups

#88

Post by hrktb »

chomp wrote: post #78
ahelwer wrote: 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.

I think that's either a team culture issue, a management issue, or a business culture issue. Teams I've worked on have had no issue brainstorming ideas for a person who's stumped. Now, I'm not totally defending standups here, I've been on teams where daily standups are a stuffy formality, and they are miserable. I've also had the pleasure of being on teams where weekly standups were implemented, and they were an abso…

In some previous team, I realized that some people working on very long tasks just gave bullshit updates. What they explained was interesting, it gave a sense of progress, and they communicated well.

Too well perhaps, their small talk was on super minor or even unrelated stuff that they saw the previous day.

They were doing mainly exploratory work, and it made no sense to bring on board other people before they settled on a direction themselves.

I think ultimately a one size fits them all approach only “works” when the people on the fringe also play the game and bullshit (in a good light) their way around.

Re: You don’t need standups

#89

Post by crispinb »

I understand many writers are desperate for views, but I'm looking forward to this nasty spreading imperative title infection to die out (which it will, but not soon enough). "What you need to know about ..." (you have no idea what my knowledge requirements are) "You don't need ..." (you won't know what I need until you find out something about me, dolt). "Why you should ..." (until you've at a minimum skimmed 'Ethics for Dummies', which your 1st-year-uni-essay-think-piece betrays no evidence of, you're not qualified to inform me what I 'should' do).

This rash is particularly prevalent in the prissy modern etiquette columns that dominate so many alleged newspapers (I'm looking at you, Graun), but the tech sector is also succumbing apace.

Now Kant: there was a guy who knew how to construct titles. He did not write "What you need to know about the categorical imperative", nor "Why you must critique pure reason".

Re: You don’t need standups

#90

Post by syncerr »

vfc1 wrote: 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…

I think it's easy for teams to feel this way depending on the mechanics of who's running standup. One of the biggest values I see for standup is talking through what you're working on. This opens communication with other engineers, especially if they default to working in isolation on their projects (even more so for remote engineers). I can't count the number of times we've had actionable changes to direction from just 5 minutes of standup that result in code reuse, uncovering unknown unknowns, etc.
Post reply on HN