Live data from Hacker News

You don’t need standups

medium.com

61–70 of 341 posts

Re: You don’t need standups

#61

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

Re: You don’t need standups

#62

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.

Re: You don’t need standups

#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. Stand ups are about communication with your peers. 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.

However, blockers do create a sense of ineffectiveness. Especially on small workload teams where task swarming doesn't net too much benefit. "Hey I am still waiting on $vendor to configure their service" or "Still waiting on netops to tag $port for vlan blah" or "Procurement put in a PO for $hardware, still waiting on it", there are times when we are waiting for something, and there's nothing able to be done currently. Especially when the immediate tasks are already doled out and your leader doesn't want to pull more work into the current sprint. Subsequent tasks could be too large or complex to be pulled in. Current tasks could be unable to be broken up any further, to which I have to say, pair program until your blockers dissipate. We do this at my current job, and it really creates tangible benefit.

As for TFA's bulletpoints on why sprints can be bad, most of their arguments are bunk except for this one:

> 4. Extroverts thrive at stand-ups, planning, and retros.

Not everyone is great at self-selling, and people who move up in the company are the ones who hype their personal brand, not necessarily those who are the best at their roles. I don't know how to solve this as it's a personality issue, but I do think it can be a problem for a lot of businesses and teams.

Re: You don’t need standups

#64

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…

>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 through the SM training and really brought into it, however, it's a difficult job to do well. Sometimes being the bad guy and telling your product owner no, or yes but here are the consequences can make you hated (literally a former co-worker and Po/PM of mine won't say more than Hi to me)

>If you can self-organize, effectively communicate, and help one another as-needed without standups

Another anecdote I have is this happening only to find out over approximately a 4 month period that we weren't good communicators, that we did need frequent structured communication to get things done right (right being the keyword). Even though this was the `smartest`, highest paid, most experienced team I've ever worked with, there was still re-work and production outages because of a lack of good coms. This probably could've been avoided if planning meetings were being attended.

Bottom line, agile processes are written in blood that you don't need to shed. Convincing a team of engineers this is the hard part.

Re: You don’t need standups

#65

I'm so in alignment with this. I've always hated standups. As a night owl, it's a morning meeting I have to make every single day and I hate it. I also don't understand how I can't just communicate in Slack to say "hey this is what I'm working on, this is what I worked on. Here are the questions I have." And move on. And if the PM prioritizes the backlog, always pick from the top just makes sense . And yes, retros fe…

We have some teams that do "slack-ins" but I find few people read the updates and even fewer questions are answered or asked.

At best, this gives micromanagers satisfaction while not doing much, and at worst it's a log of "well I told you so"

Re: You don’t need standups

#66

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…

The one thing that I like about standups is that they make real blockage or ineffectiveness more visible.

It is true in theory that you can get the same thing from just scanning the project board every day. But people don't actually do it. Furthermore if you're stuck on X, standups are a perfect time for someone who was about to look for a ticket to take one off of you that they are better suited to handling.

Are they perfect? No. There are definitely false positives. But the ratio of real positive to false one is good enough that they provide real value overall.

Re: You don’t need standups

#67

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…

[deleted]

Re: You don’t need standups

#68

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…

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

The idea of standups and breaking down work into chunks that fit in a short sprint is to avoid this sort of situation where somebody is off on their own and not getting feedback.

I find that people are overly optimistic about their chances of getting a task completed in the promised time frame. If something is expected to take five days, I'll hear every day that it's going well, right up to the last day, then all of a sudden it's not going to be done. The more granular the task is, the easier it is to deal with slippage because you get to know about that slippage sooner.

Re: You don’t need standups

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

Re: You don’t need standups

#70
I'd guess this is probably only possible at a cash flush company where the devs personally use the product and fully understand the cost/benefit trade offs. Also, those sorts of meetings aren't for the sole benefit of the engineers.
Post reply on HN