Live data from Hacker News

You don’t need standups

medium.com

181–190 of 341 posts

Re: You don’t need standups

#181
We do stand ups once a week on Monday morning to get everyone on the same page and focussed for new week.

Each time a different dev runs it, chosen by the person who ran it last.

Our stand ups are one of the most mentioned things in my 1:1s as everyone likes to hear what other people are working on.

We then do a retro on Friday afternoon, sit outside and have a beer and chat about what worked and what didn’t.

Not strictly agile, but this works for us and everyone is happy and productive.

Re: You don’t need standups

#182
post #93

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…

Because you work in the team.

A boss used to say to us, you haven't proven you know how to do it until you've done it twice. This is, as I recall, also the guy who would pigeonhole people who built things that they couldn't hand off to others. He fed us some bullshit line about being 'too important' to work on the new cool stuff. It was a hard lesson but I learned pretty quick to put extra time in to make my code obvious to others instead of just me. Boost your truck number if you ever want new scenery.

(Most of my coworkers thought he was being sincere in his flattery rather than being ironic. For all I know they are still being 'too important' to work on new subsystems.)

Re: You don’t need standups

#183
post #86
post #78

Earlier quoted context omitted.

I think that's either a team culture issue, a management issue, or a business culture issue. Teams I've worked on have had no issue brainstorming ideas for a person who's stumped. Now, I'm not totally defending standups here, I've been on teams where daily standups are a stuffy formality, and they are miserable. I've also had the pleasure of being on teams where weekly standups were implemented, and they were an abso…

Are stand up meetings the correct venue for brainstorming?

No, but they can spur an interested subset of people to brainstorm after the standup ends.

Re: You don’t need standups

#184
post #174
post #69

Earlier quoted context omitted.

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.

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's our goal for today? 2) what might block us or slow us down? 3) how are we going to tackle our goal?

When stand ups start feeling like justifying your existence then morale drops, [looking] busy work increases, and too much time is spent on CYA. Focus on solving problems not explaining them.

Re: You don’t need standups

#185

Earlier quoted context omitted.

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

I'm becoming increasingly convinced that, to be successful, a team's agile practice needs to largely fly under the radar of upper management.

As soon as upper management catches wind, you'll need to justify every little process flow change to them, or they'll start demanding regular reports with burndown charts and plots of velocity over time and crap like that. At which point, you're done. Things officially suck forever.

That isn't to say that I think Scrum coaches and whatever have no value to offer. I've done a 1-week Agile training course, and I thought it presented some really great ideas. But their potential value is severely undercut by the fact that there's no way to bring one in without attracting the attention of the mothership.

Re: You don’t need standups

#186
post #184
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…

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

Re: You don’t need standups

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

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

Oh! Just don't give the show people a stage.

You know a stage — like daily standups or so…

Re: You don’t need standups

#188

The entire concept of a sprint to me always felt wrong. Development work can't be split up into time slices. And trying to divvy up tasks based on an estimate of how long it'll take to complete each one is just a waste of time. I remember being in a standup, being told to bump a high-priority task into the next sprint and complete a couple low-priority tasks instead because I already had too many points assigned to m…

>The entire concept of a sprint to me always felt wrong. Development work can't be split up into time slices. And trying to divvy up tasks based on an estimate of how long it'll take to complete each one is just a waste of time. That's because sprints weren't designed for us. They're designed for management. Product managers and VPs need to be able to think of their "resources" in manageable, discrete chunks. Vagarie…

They should be designed for us. The idea is supposed to be that there are limited times that developers are negotiating with the outside world about what exactly they are working on. The rest of the time, nobody gets to interrupt and demand that they drop everything and jump on to their latest crazy idea.

But yeah. I currently have to wear both the PO and dev hats, and, when I'm wearing the PO hat, I also see advantages: It means that I get to have a rhythmic schedule that I can set my calendar to. That makes all the orchestration crap so much easier.

Which, incidentally, I also like from a developer perspective. The less time I have to spend on that stuff, or get randomly interrupted by that stuff, or randomly interrupt people with that stuff, the more time I get to spend on actually building stuff.

Re: You don’t need standups

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

Story points are like BMI: They're meant to be accurate enough that, when you aggregate them over a whole bunch of items, you end up with a reasonably reliable time estimate. But they're a terrible measure of time to complete an individual task. They were never meant to be such a thing in the first place.

That's why the canonical Scrum books always say that the PO can use story points to (roughly) estimate completion dates, but the development team should never use them to figure out how many items to accept into the next sprint.

Re: You don’t need standups

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

>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

You need a strong manager or leader willing and able to reign individuals in. This person needs to open the discussion space to others and prevent the loudest (and it sure seems often like the most opinionated) from interrupting.

Post reply on HN