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

201–210 of 341 posts

Re: You don’t need standups

#201

Post by brown9-2 »

some_account wrote: post #82
chomp wrote: 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…

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…

are you really on a team then?

Re: You don’t need standups

#202

Post by tejaswiy »

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…

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 sprint goal? What will I do today to help the development team meet the sprint goal? Do I see any impediment that prevents me or the development team from meeting the sprint goal?"

These questions are effectively a way lay out a very clear path for management to basically micro-manage developers and they add pressure on developers to come up with some contrived explanation to make it sound like their day was productive. Hardly builds any trust when your work is being supervised and judged by a team every single day even if the goal of the meeting is not to do so specifically.

I can go deeper into each individual process that agile variants impose and take each of them apart. I have nothing but spite for this godforsaken process, the only thing it's good for is to give management an illusion of control on software development process.

Re: You don’t need standups

#203

Post by JustMatthew »

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.

For technical or non-technical teams, this is usually all that's needed. If there are any questions, they can be addressed below in a reply thread or via a call or face-to-face.

It's amazing how much of a time saver and efficiency builder that can be. It's equally amazing how many managers prefer time wasting group meetings where people essentially read written reports...

Re: You don’t need standups

#204

Post by seancoleman »

I've been beating this drum as it's one of the more frequently cargoculted items about agile.

A standup has 3 questions to report on:

1. What did you make progress on yesterday?

2. What are you planning on making progress on today?

3. Do you have any blockers?

Taking this pulse once every 24 hours is artificially constraining. Relevant stakeholders (product people, other engineers, project managers, etc.) should have perfect, frictionless visibility in to what people recently worked on, and what they are planning to work on at any given time, as self-reported by the team. Additionally, if you have a blocker, you should not wait until the next standup. Unless the blocker was discovered immediately preceding the standup, it should be well known to all who need to know with the same perfect, frictionless visibility. At the time of the standup, blockers should be well-known. I've specifically seen standups backfire as individuals use reserve their blockers until the next morning. It's a great reason to call it an early day when you hit a blocker and get the opportunity to report something of substance at the next day's standup.

Perhaps I just described an unattainable utopia, but I think it's important to start with process idealism and make considered compromises rather than acculturating the status quo.

I lead an entirely remote-first development team, and am adamant that standups often are a crutch at best, and inhibit progress at worst.

Re: You don’t need standups

#205

Post by dragonwriter »

tejaswiy wrote: post #202
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…

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/progress check, it should be a venue for shared progress on breaking barriers.)

Re: You don’t need standups

#206

Post by inv »

I've worked at 5 different companies that did standups. They always sucked. Agree with what others said here: If you need to talk to someone, just do it, don't wait for the next day.

The team that didn't do standups was by far my best team. We still talked frequently as needed and moved quickly. Actually quicker because we didn't get interrupted by standups, hour long retros and planning meetings.

Re: You don’t need standups

#207

Post by paulddraper »

jrs235 wrote: post #184
munk-a wrote: 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…

Though what you are doing today is a direct result of what happened yesterday.

Re: You don’t need standups

#208

Post by t0mbstone »

darkr wrote: post #154
t0mbstone wrote: post #140

Earlier quoted context omitted.

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…

Just because you swapped the word "time" with "distance" doesn't mean you aren't still talking about time.

Distance from what? How far it is from now until when the work will be done. You are still talking about time.

I feel that swapping out the term with one that is more vague is, at worst, disingenuous, and at best, counter-productive.

Re: You don’t need standups

#209

Post by speby »

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…

"still workin' on those bugs" is really pretty useless. I'm not suggesting you're not a disciplined person but at some point, debugging something for days on end is a sign you may need some help, a fresh set of eyes, or come up for air and re-group. Same goes for feature development. If a single user story representing a whole feature (or part of a larger one) goes on and on and on, that's either a sign you perhaps rabbit-holed it too deeply, need some help from another team member, or need to raise a flag and split the story into another piece, possibly even one someone else can rally around to help close it.

Re: You don’t need standups

#210

Post by mattmanser »

tejaswiy wrote: post #202
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…

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…

If you read the agile manifesto and then you look at scrum, it feels as if scrum has nothing to do with agile. It seems to breaks every rule.

Scrum is processes and tools over individuals and interactions, by its very nature.

Scrum is comprehensive documentation over working software, because you have to map everything out.

Scrum is contract negotiation over customer collaboration, by allowing management to effectively rule scrum, scrum masters are always management or reporting to management, so devolve into contract negotiation by proxy.

Scrum is following a plan over responding to change, again, by its very nature.

It's the most odd thing I've ever seen, that somehow scrum came out of agile and literally got it all backwards. There's even certifications on how to do scrum, which is utterly stupid when you read the 12 principles, some choice scrum oxymorons:

trust them to get the job done - nope, we don't trust you, follow these scrum rules you oiks

simplicity is essential - but we've got all these formal rules for you to follow

working software is the primary measure of progress - no, actually, how many sprints have been successfully completed?

the best architectures, requirements, and designs emerge from self-organizing teams - but we're not going to let you self organize, you must follow these scrum rules

Post reply on HN