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

251–260 of 341 posts

Re: You don’t need standups

#251

Post by QualityReboot »

mr_tristan wrote: post #215

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.

Re: You don’t need standups

#252

Post by barrkel »

dragonwriter wrote: post #205
tejaswiy wrote: post #202

Earlier quoted context omitted.

That is just bullshit though. I don't find value in anything that agile offers, can I just throw it out entirely by your argument? Standups - You can simply claim that, hey you don't want to do standups, don't do standups but if you take a concrete implementation of Agile, say scrum for instance, it specifically asks each person in the team to answer: "What did I do yesterday that helped the development team meet the…

> These questions are effectively a way lay out a very clear path for management to basically micro-manage developers Well, they would if there was manager in the daily scrum. Which is why there isn't. (Not that I think the scrum formula here is ideal; if you've got a shared status display—kanban-like—the only question you should really need in the standup is the barriers one; the standup shouldn't be a status/progre…

If it's not a dev manager, it can be a product manager / owner / scrum master / whomever is in charge of roadmap and high-level backlog items.

They take control because they've made promises to other people, higher up in the org and possibly outside the company, and they need to find out if scope is expanding too much, if something is taking too long to implement and scope needs to shrink as a result, or people who've been promised something need to be let down.

As a developer, this interaction feels a lot like micro-management.

Re: You don’t need standups

#253

Post by gav »

BigJono wrote: post #220
gav wrote: post #68

Earlier quoted context omitted.

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

A task should be something that can be done independently by one person. Sometimes you have a big chunk of work that's tightly coupled and can take months to implement, how do you best track that? In my experience what happens is one of three things: (a) You try and bring multiple people into that feature and it turns into a clusterfuck of awful merge conflicts and hours upon hours wasted on co-ordination instead of…

I struggle to think of an example where I'd ever let somebody go off and work on something for months. I can't think of how they would be successful, let alone take on the risk that they quit or get hit by a bus and nobody can continue the work.

Re: You don’t need standups

#254

Post by no_one_ever »

LargeWu wrote: post #121

Here's a thought experiment, and a challenge: When was the last time you learned something really important at a standup meeting that you wouldn't have learned otherwise, either by talking to someone directly or in some form of asynchronous communication? I bet it was a while ago, if you can even think of anything specific. Standups, in my experience, are a net negative, in that there is a cost, but rarely a benefit.…

I can hardly remember the last time I personally learned something just from attending a standup, but I guarantee I've taught other developers a thing or two regarding their problems and tasks that they otherwise would have floundered about trying to solve on their own. Just because it doesn't benefit you doesn't mean it doesn't benefit the team and project.

Re: You don’t need standups

#255

Post by jrumbut »

still_grokking wrote: post #191
hrktb wrote: post #88

Earlier quoted context omitted.

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.

It's a trade off. Some of the communication is very valuable, and needs to happen for coordination, knowledge sharing, etc. The potential harm of that communication not happening is great, the risk of having a meeting go 15 minutes longer is worth trying to avoid (hence the article) but much smaller.

However, if only some people speak that can create divisions in the team, or make it look like the speakers are the leading members when that may or may not be true. So to prevent that dynamic everyone says something, and people can help the team function better by coming up with a nifty one minute oration.

Ultimately making software is a human endeavor. Sometimes a little small talk prevents the humans from feeling bad and not making software. Sometimes it has the opposite effect.

The best managers figure out which case is true at a specific time and place and adapt. Good managers just have to pick what risks to take and live with the outcome.

Re: You don’t need standups

#257

Post by tomjakubowski »

LargeWu wrote: post #121

Here's a thought experiment, and a challenge: When was the last time you learned something really important at a standup meeting that you wouldn't have learned otherwise, either by talking to someone directly or in some form of asynchronous communication? I bet it was a while ago, if you can even think of anything specific. Standups, in my experience, are a net negative, in that there is a cost, but rarely a benefit.…

> Here's a thought experiment, and a challenge: When was the last time you learned something really important at a standup meeting that you wouldn't have learned otherwise, either by talking to someone directly or in some form of asynchronous communication?

Twice this sprint, a problem I mentioned at standup was addressed at that moment by a comment or suggestion from a teammate. The standup is really the only venue I have to casually, non-directionally vent frustrations I'm facing. They're great.

Re: You don’t need standups

#258

Post by paulie_a »

refoundglory wrote: post #233
scribu wrote: post #186

Earlier quoted context omitted.

> what's our goal for today? The same as it was yesterday or whenever the last planning session happened. Like TFA said, the team, as a whole, shouldn’t be changing priorities like socks.

If your goal for the sprint is "build widget" then your goal for the day should be "build part 3". You don't change priorities each day, you change how far along you are and where you expect to get to.

The term "Sprint" makes me cringe, it's meaningless in my experience. It doesn't effectively identify goals or deadlines. It's a stupid techie/hipster term that no one apparently pays attention to.

Re: You don’t need standups

#259

Post by dragonwriter »

barrkel wrote: post #252
dragonwriter wrote: post #205

Earlier quoted context omitted.

> These questions are effectively a way lay out a very clear path for management to basically micro-manage developers Well, they would if there was manager in the daily scrum. Which is why there isn't. (Not that I think the scrum formula here is ideal; if you've got a shared status display—kanban-like—the only question you should really need in the standup is the barriers one; the standup shouldn't be a status/progre…

If it's not a dev manager, it can be a product manager / owner / scrum master / whomever is in charge of roadmap and high-level backlog items. They take control because they've made promises to other people, higher up in the org and possibly outside the company, and they need to find out if scope is expanding too much, if something is taking too long to implement and scope needs to shrink as a result, or people who'v…

> If it's not a dev manager, it can be a product manager / owner / scrum master / whomever is in charge of roadmap and high-level backlog items.

In by-the-book Scrum, that's the Product Owner, who isn't a participant in the daily scrum. Neither is the Scrum Master, whose only roles with regard to the daily scrum are: (1) teaching the Dev Team to keep it within a 15-minute time box, and (2) ensuring that it occurs, (3) ensuring that if people other than the Dev team are present, they do not disrupt the scrum.

(I do think that both having the status questions and leaving the door open for the P.O. to be present even if not supposedly participating is a thing that creates the temptation to turn the scrum into a managing meeting, which is very explicitly not the intent.)

Re: You don’t need standups

#260

Post by stevebmark »

This makes me suspicious of Spotify. This is bad advice that could maybe apply temporarily to teams where you're not working on mission critical business work (what is left to engineer at Spotify?)

I also don't like that he prefixed bad advice with "PERSONAL beliefs" as a cop-out for responsibility. This is a tactic used by people skirting ownership of ideas.

Post reply on HN