Live data from Hacker News

You don’t need standups

medium.com

191–200 of 341 posts

Re: You don’t need standups

#191
post #88
post #78

Earlier quoted context omitted.

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 settl…

It's a good idea to waste valuable engineering time with "bullshit" (in a good light) small talk? OK…

I likely will never understand the great minds behind management.

Re: You don’t need standups

#192
Standups is just another example of something that someone had to makeup for the Agile methodology in order to be able to say that "people are communicating"...kumbaya.

It was probably invented by the same guy that invented the demented concept of open office.

Re: You don’t need standups

#193
post #87

Earlier quoted context omitted.

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.

> they have no agency to change anything If this is the case, than that's a sad state of affairs for the team. Instead the Team should have retrospectives to freely talk about, what processes/ceremonies work and add to the teams efficiency at getting things done and which do not or are even detrimental. With each iteration of a retro the Team should slowly but surely progress towards a local optimum, where they shape…

"If this is the case, than that's a sad state of affairs for the team. Instead the Team should have retrospectives to freely talk about, what processes/ceremonies work and add to the teams efficiency at getting things done and which do not or are even detrimental."

I mean, that sounds great, but in many of these situations, which are quite sad, the biggest problems they face are management that doesn't completely buy in, but still wants to tout that they're "Agile". So no getting rid of any ceremonies.

"With each iteration of a retro the Team should slowly but surely progress towards a local optimum, where they shaped their work environment such that they can work best."

Again, not all the issues are ones that the Team directly can address.

"Stand-ups should be only for the team and SM."

Should. Should is the operative word there. And I understand what you're trying to say in your comment, but it just completely ignores what reality is like at some places.

Re: You don’t need standups

#194
post #80

Earlier quoted context omitted.

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.

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

I didn't mean to imply that, but one of the purposes of stand-up is to give a place for that to happen.

Re: You don’t need standups

#195
post #184
post #174

Earlier quoted context omitted.

I think your team is too big then. Don't have company wide standups, have a standup per team and possibly role. If you're working on a web stack have a standup where the backend devs talk, one for the DBAs (if that's a thing you have) one for the front-end people... If there's someone in a product manager role they might want to attend all the meetings but likely not. If a clear majority of the audience isn't interes…

>If a clear majority of the audience isn't interested in your status then you're just burning hours. From my understanding stand ups are not supposed to be status reports. They tend to turn into them though as it seems the most common format is 1) what did you work on yesterday, 2) what are you working on today, 3) what's blocking you? I prefer daily stand ups (near the onset of the day) for small teams to be 1) what…

If you're doing kanban and work in an environment where product direction changes quickly, then definitely this.

If your standup can be replaced with everyone posting on a slack channel, then it's just a status update as there's no discussion and alignment happening, which are the valuable parts.

Most teams should experiment with their process more.

Re: You don’t need standups

#196
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…

That reminds me of a job that wanted detailed reports every day. So I ended them with "and I spent the last hour of my work time writing this report".

They eventually saw the light. I was one of the two people charged with firing the incompetents.

Re: You don’t need standups

#197

Earlier quoted context omitted.

1. Agile is not personally great for programmers. 2. Agile is good for managers. 3. Managers run the business and make sure it exists. 4. Programmers need the business in order to have a job. 5. Agile is therefore good for the business, 6. And therefore Agile is good for Programmers, though not personally.

I would disagree with almost every claim on this list.

Agile is good for managers who are unable to evaluate their programmers otherwise.

Re: You don’t need standups

#198
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…

Not really a fan of standups either, but I want to express a counter point: developers consistently over-estimate their understanding of the problem domain they are working in and the wider context it sits in. That is yes, managers don't "trust" developers - but not in quite as negative a sense as you think. There is a positive aspect of supporting the person, ensuring they are connected to the right resources to succeed and stopping them getting stuck on things that don't matter.

I have a small team of devs and I consistently find that given task X they will get stuck and end up spending a lot of time on small subpart Y. And they really want to solve Y, because they are engineers and doing the "hard" stuff is what often drives them. So without some kind of input, what they will do is spend a week on Y and then report back that X was much harder than expected. When told at that point "Oh, we really actually don't need the Y part, we could just to Z instead" they will be quite disappointed, and wonder why they weren't informed that Y wasn't that important to begin with. So more regular communication of some kind is really important to avoid this. As I mentioned, I don't really like daily standups as the optimal way to achieve it ... but I don't quite accept the "leave your developers alone for weeks at a time" strategy either.

Re: You don’t need standups

#199
I've pushed for this model and I've done this with my team over the past year. It's worked out relatively well, but not as well as I expected. Context: I am the lead developer on the team, I am not a people manager.

Our work involves some research which we've managed to do quite well following this model. We've also evolved our product and managed to deliver complex features more efficiently than we would have done if we did sprints, IMO.

A few team members have complained about lack of frequent deadlines (?!?), lack of status meetings/standups etc. The arguments are weak IMO - 'that's how we did it before', 'we hear what other people are doing' (we are pretty good on transparency), 'it's nice to have a forum to discuss how things are going' (we use chat extensively and we should be able to discuss things there). Our manager is great and he helps people choose which things to work on - he's been handling feature prioritization and he's making sure that people are comfortable with their work during 1:1s.

Also, I think it's really important to have a clear vision and steer the product - we've been missing that and it's caused a lot of friction when deciding how to evolve the product. Sprints wouldn't have fixed that, but maybe a more rigid decision making process would have made us fix the problem (or at least complain more) earlier.

Re: You don’t need standups

#200
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…

> Having to hunt down tasks you're working on and reading through each task can create an unnecessary mental load that can be solved with a single 1 minute "ESPN sportscenter edition" summary of your current issues.

Some people indeed need spoon feeding. That above statement only strengthens my view.

Or how do we interpret "unnecessary mental load" out of the mouth of someone likely in management when it comes to simply reading a task board?

Sometimes I really wonder what most of the management is good for… Really.

Running around, having a lot of meetings, but nevertheless not knowing what is happening all around them, so they have to ask every day anew…

But now I understand: It's only a unnecessary (too height?)^^ mental load to read the task board. :-)

Post reply on HN