You don’t need standups • Hacker News Board

Re: You don’t need standups

#151

Post by fiachamp » Thu, Aug 02, 2018, 9:23 PM UTC

Benjammer wrote: post #92

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…

It's worse than "assembly line worker." For that, a hyper-specific set of actions is created, and then commoditized workers are inserted into this rigid process. The spec/actions rarely change over time. In "what did you do yesterday?" stand-ups, the worker is expected to establish their own personal direct actions in order to meet outside expectations and goals set by their manager/team. And then every morning someo…

In orgs I've been in the daily standup was clearly intended to help people get a heads up on who can help them with blockers or may be working on a similar part of the codebase that day. It also helps PMs know what kind of support they'll need to give their dev team that day since they often get pulled into meetings by other parts of the company.

As far as timeboxing, the PM is timeboxed by having stuff in good enough state of definition that their devs feel they can work on them. So if you don't have your specs there by the time sprint planning happens, your projects don't get done and you risk your job. Of course, we have an issue if the PM is writing shitty specs and not around to help answer edge case questions.

Re: You don’t need standups

#152

Post by grimjack00 » Thu, Aug 02, 2018, 9:24 PM UTC

deanCommie wrote: post #62

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…

"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 is how I view it: - "big A" Agile has books and approved tools and coaches from outside the company holding week-long all-day workshops. - "little a" agile has devs/QA/etc. suggesting ways to make the process of building and shipping software smoother.

I'm currently working on a "little a" agile team. Upper management doesn't really care what our process is, as long as they get their quarterly release with (most) of their priorities.

Re: You don’t need standups

#153

Post by nrbernard » Thu, Aug 02, 2018, 9:29 PM UTC

com2kid wrote: post #44

Line by line: > Trello (or whatever you use) has to be kept in sync with what’s discussed in these meetings. It often isn’t. My team offloaded this to the PM. > Stand-ups ENCOURAGE plans to change daily. The sprint plan is the plan, stand-ups make sure the execution is coordinated. > Standup forces every team member to be productive at a set place and a set time Timing around standups is interesting. 11am and everyon…

> Plan tech debt into your sprints.

Exactly! Nothing about Scrum or Agile discourages tackling tech debt. Managers and Product Owners encourage features—not sprints.

Re: You don’t need standups

#154

Post by darkr » Thu, Aug 02, 2018, 9:32 PM UTC

t0mbstone wrote: post #140

darkr wrote: post #129

Earlier quoted context omitted.

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

And yet, story points are used to estimate how much work a team can get done in a sprint, which is a time measurement... and they are used to track velocity, which is used by management to figure out when a project might be completed (also a measurement of time). "Oh, story points are just about the complexity" Oh really? Why does complexity matter, if not to function as an indicator of how long something might take…

Absolutely, story points are used as a component in the estimation of time.

Story points on their own are useless though; they are an abstract thing that only means anything to the team and it’s velocity.

A good analogy is that they are an estimate of distance. Knowing roughly how far something is away does not tell you how soon you will get there. You can only do this by working with an average of how fast the team can go.

If the team is terrible at estimating distance, then the velocity will reflect that and gradually self-correct.

Re: You don’t need standups

#155

Post by iEchoic » Thu, Aug 02, 2018, 9:33 PM UTC

TooBrokeToBeg wrote: post #150

iEchoic wrote: post #147

Is there any reason to believe that a process that interrupts an entire team every day to make everyone listen to non-critical updates would be necessary? Standups are (in my experience) usually a symptom of a low-trust environment, where there's an underlying belief that engineers will do less work or let things slip without the fear of being behind at the next standup. In some companies, this is actually true - so…

> Standups are (in my experience) usually a symptom of a low-trust environment and or a high volatility process and or poor information flow. All of these things occur at different times throughout any company. Standups mitigate these issues and are not supposed to be these hour marathons that I see everywhere.

Agreed that those are other common causes.

I think that keeping standups short does very little to mitigate the damage they cause, though. The biggest cost isn't the time they take, it's the act of forcing your entire engineering team out of a flow state (or worse, forcing them to wait until after standup to even start) on a daily basis. That happens regardless of if they're 10 minutes or 30 minutes.

Re: You don’t need standups

#156

Post by chris11 » Thu, Aug 02, 2018, 9:42 PM UTC

VectorLock wrote: post #112

hfourm wrote: post #102

I think a lot of the themes in this article I can agree with, but I come away with the overall impression that the author hasn't necessarily worked in a healthy agile environment before. Basically, I agree with many of the conclusions (or solutions) but disagree with a lot of how the author came to them. Standups aren't inherently bad. Also it sounds like he moved his team to more of a kanban style workflow -- which…

I got the impression that the author of the post had worked in effective agile environments and he came to the conclusion that the cargo-culted trapping of agile were unnecessary.

I was a little bit surprised to see this article with him at Spotify. Their Squads framework is shown as an example for larger-scale agile, I heard about it at a place that had just started doing SAFe. The approach mentioned in the article doesn't really match up with my idea of larger-scale more corporate agile.

Re: You don’t need standups

#157

Post by amai » Thu, Aug 02, 2018, 9:43 PM UTC

I read "You don't need startups" and nodded my head in agreement.

Re: You don’t need standups

#158

Post by RussianCow » Thu, Aug 02, 2018, 9:47 PM UTC

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…

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

I find this concept very strange. Maybe it's just me, but aside from one time where the agency I worked for briefly had no ongoing client work, I don't think I've ever felt like there was no work for me to do. At all my past jobs we have always had a large list of small, low-priority tickets that people can pull from if they are blocked on their larger tasks. Is this not the case at some companies?

Re: You don’t need standups

#159

Post by RussianCow » Thu, Aug 02, 2018, 9:52 PM UTC

losteric wrote: post #77

kolinko wrote: post #33

Earlier quoted context omitted.

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.

My team just does "asynchronous stand-ups" - share your status once day in a dedicated Slack channel, whenever you want. We do this on top of a good culture of asking for help and posting regular updates on our internal Sprint tracker, it works quite well.

I think this is the correct way to do standups for most teams. It's asynchronous and non-intrusive, and there generally isn't any benefit from doing the standup in person anyway (aside from seeing people's faces if your team is remote).

Re: You don’t need standups

#160

Post by Benjammer » Thu, Aug 02, 2018, 9:56 PM UTC

nawgszy wrote: post #114

some_account wrote: post #82

Earlier quoted context omitted.

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

>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? >it makes them share if they are thinking incorrectly about something >it makes them easily replaceable I think the thing that makes you easily replaceable is if you constantly are thinking incorrectly about something and are unwilling to be corrected by teammates because you a…

This mentality is the root of the problem (from the dev perspective). The GP commenter is saying "these processes don't help me to feel that I've done my job better."

And you respond with "Well, this sounds like you aren't good at proving you're not a _complete idiot_."