Live data from Hacker News

You don’t need standups

medium.com

301–310 of 341 posts

Re: You don’t need standups

#301
post #63

Earlier quoted context omitted.

"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 sim…

That was my thought too.

If it's an unnecessary mental load (for developers or managers) to find out about the tasks currently being worked on and what they are, then the problem is with your work/task tracking system, not with your developers.

Re: You don’t need standups

#302
post #299

I really dislike these type of articles. The title is there just to shock you, and so is the content... so much that there's a disclaimer at the end of it. I think I would read it with an open mind if the title was phrased differently... "Maybe you don't need standup" or "how standup slows down our company" something of that sort. "The natural side effects of not doing standup are:" "- Developers communicate more - Y…

Our team of developers is 100% remote and we do a daily standup each morning that lasts anywhere from 15-30 minutes. Each person runs through anything of note from yesterday, our priorities for the coming day, any roadblocks, and anything we feel like discussing with the team.

Coming from a team that did nothing remotely close to a standup, I highly value our current system. It's not perfect, and I have no idea if it fits the Valley's definition of "standup", but it serves its purpose very well and keeps everyone on the same page. I can't tell you how many times a person from my team has reached out in the afternoon about a roadblock I mentioned during standup. Or how many times a team member wanted to help me out on a tough user story simply because I was open about discussing its difficulty.

This is just my opinion.

Re: You don’t need standups

#303

Earlier quoted context omitted.

Things being recognised and never/rarely acted on is better than them going unrecognised entirely. At least in the former scenario, there's a shared awareness of the problem.

There isn't. Raising an issue without ever fixing it is very demotivating and causes a "fuck it" attitude.

Everyone being aware of an issue without it ever being raised or acknowledged is equally demotivating and results in the same attitude.

Re: You don’t need standups

#304

I'm the scrum master on a team where most members are very geographically spread out, and the standup is great. It's time for everyone to have that direct social connection. But I don't ask about ticket status. We just ask about what they did yesterday, and what they're up to today. And I mostly ask that if they aren't doing something already captured in a ticket, make another one, so we have a record of issues takin…

Why doesn't everyone just write what they're up to today in a chat channel and people can reply if they want? It seems kind of silly to me to have everyone dial in or stand around in a circle, to each have one person speak. I'd much rather see a list of what's going on with everyone today and if anything catches my eye, I can talk to them about it.

It creates silos.

We do this on occasion, sometimes people are out, and there's just a few of us around.

I _never_ see social interaction when people do that via chat. It's the same thing as just updating your ticket.

Re: You don’t need standups

#305

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…

This is especially true if you're working on a research task, or the research portion prior to really driving in and implementing the feature. Every day you're basically saying the same thing and it looks like you're struggling, but you're mostly just learning.

Re: You don’t need standups

#307

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…

Can you articulate an example of a good versus a bad standup? Because your response is pretty vague. I've been on a lot of teams, read a lot about Agile and SCRUM, and just about every single one communicates stand-ups as a status update, not what you are indicating at all. If this was an isolated thing, I would agree with you, but when almost everyone is doing it this "wrong" way, as you say, I think the problem is with "agile," as loaded as that term is these days.

I don't even understand how you can get together to "move the project forward" and it be under 5 or even 15 minutes. What does that even mean in practical terms? That kind of open-ended question usually devolves into many different unfocused discussions and then pretty soon everyone clearly wants to leave.

Re: You don’t need standups

#308
post #283

Earlier quoted context omitted.

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…

> The rest of us met every morning for breakfast. No standing up, no meeting. But we knew what we had to cover in between shooting the crap. We did well. He did not. Basically, since the other guy did not wanted standup you intentionally left him out of loop and communicated only among yourself during breakfast. If there was ever ugly politics, it is this one. > He finally came. Every morning the team would have fun…

Maybe they were being toxic, but it simply seems like they took a little time in the morning to go over things and he chose not to join them. So what should they have done, each staged separate little talks with him to go over everything that was discussed in their morning meetings? Compile meeting notes and send them to him?

It doesn't sound so much like sabotage as it does that he chose to put his head down and eschew the meeting and struggled because of it.

Re: You don’t need standups

#309

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…

"agile" is great. "Agile" has been fucked to death by consultants and execs who just heard "wait you can make developers completely fungible and i can get something in 2 weeks rather than waiting for 2 years?" and never bothered to listen to anything else.

That's a strange reading of Agile to me. Agile is not about making developers fungible, it's about building high performing teams of people. That takes time, and it is set back any time you have to replace someone. There's plenty of Agile literature that points out the hit to velocity when there's turnover.

As for 'i can get something in 2 weeks rather than waiting for 2 years', that's about not waiting 2 years to find out that you've been building the wrong thing or that the software sucks. Maybe as you deliver features you'll find out that the application is good enough in 18 months. Maybe you'll find out after several months of sprints that the product owner is bad at getting requirements and you need to do something different. Or maybe you'll find out that it is taking longer than original estimated to deliver functionality so important dates need to be adjusted accordingly.

In the old waterfall model, all that bad news may not come out until 2 years later when the software is released. And in the old model the customer is not getting useful software until 2 years out, rather than much sooner with a minimally viable product.

Agile is not a panacea and any methodology will fail if attempted by dysfunctional/incompetent groups of people. But if there's one benefit of Agile, is that everyone should find out much sooner that things are going awry.

Re: You don’t need standups

#310

One of my manager used to say that number of status meetings you must to do is inversely proportional to quality of people you have. The whole concept of standups and scrum was started to bring highly dysfunctional team back on track. Since then now we have been applying methodology that is required to make highly dysfunctional teams work to all teams.

Agile is the management equivalent to electron apps, not very efficient but makes your job easier.
Post reply on HN