Live data from Hacker News

You don’t need standups

medium.com

331–340 of 341 posts

Re: You don’t need standups

#331
post #129

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…

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

> If you're directly equating story points to time then you're doing it wrong.

But it's not us, the developers, doing this conflation. It's management. No matter how many times we say "story points are useless without a consistent measurement of velocity", they still say "okay, but 2 + 5 + 3 + 2 = 12 dev days, so you and Jane can have ${FEATURE} done on Tuesday, right?"

Re: You don’t need standups

#332

Let's say you have 2 developers: - developer A wants to get promoted as quickly as possible. developer A will try to "ship" as many features as possible. - developer B wants features to actually work, not just be "shipped". developer B volunteers to fix the problems developer A created by rushing to close as many tickets as possible. Now, guess which developer contributes more to the team "velocity"? developer A. But…

Or do developer A and developer B make a good team? Looks like you've got a starter and a closer there to me.

Sometimes that is indeed the case.

In other cases you need a full rewrite, and that is not good.

Re: You don’t need standups

#333

As someone who hates standups I tend to disagree. I've found that without some kind of forced daily interaction, lines of communication in a team break down very quickly if they aren't already extremely tight knit. Once that happens, your project is toast.

That's funny because we recently started doing standups and our communication has fallen off a cliff. I feel like we had that tight knit group you describe, knowing when to get in touch and when to leave things alone.

Now we don't speak to each other except during standups, and even then it feels more like speaking at each other as it is expected that each member put in their voice, even when they have nothing to useful to add, leading to the team quickly tuning out and then not paying attention when something important is mentioned. Not to mention that now there is up to a 24 hour window before anything is addressed, when the previously used ad-hoc meetings would have got everyone on the right track in a much shorter timeframe. And as a result of all that I feel like there is a lot more animosity between members.

It may be possible to do standups well, but we've failed at it horrifically.

Re: You don’t need standups

#334
post #6

I'd really like to hear thoughts on how this applies to remote teams. I find that async standups via slack are pretty damn helpful for keeping everyone appraised of what is going on across 5 timezones. Process and communication are kind of key, aren't they?

Async standups do well only if the engineers have the discipline to actually go through them. My past experiences have shown a couple devs paid attention to the standups to look for issues and everyone else just typed their own up without looking at what other people wrote.

This is what everyone does in person too. The people that go last tune out because they're preoccupied about what they'll say and the people that go first stop listening because the value of the information tends to be very low.

Re: You don’t need standups

#335

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's a strange reading of Agile to me. Agile is not about making developers fungible, it's about building high performing teams of people. That takes time, and it is set back any time you have to replace someone. There's plenty of Agile literature that points out the hit to velocity when there's turnover. As for 'i can get something in 2 weeks rather than waiting for 2 years', that's about not waiting 2 years to fi…

I've worked in waterfall and agile for 15 years, and the key lesson from Scrum is that it effectively exposes bad news early on. The scrum ceremonies do just that and nothing more. Once you get the bad news open and dealt with a lot of other work is made more worthwhile.

Re: You don’t need standups

#336

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…

I really don't get this "management can micro-manage developers". Sounds like you work at a very shitty company / unhealthy environment. Dailies are for the actual working team, so they work better together and not a tool for team externals to shit all over the process. I really can imagine your scenario - do you really have your CEO standing there on your daily meeting? Or are you bothered by your Team Lead? I'm a C…

Without scrum, if a CTO wanted to ask how an individual developer is doing, they could ask their line manager. With scrum, a CTO could just dig in to some of the many dubious reports that scrum generates. They could look at an individuals burn-down on tasks, and compare them across developers/teams. No matter how stupid this sounds, I've seen this exact thing being done by company Directors.

Decisions are made. Developers are moved to different projects, or given shitty bonuses, or constantly hassled to make their scrum metrics look better.

Just because you don't go to a stand up doesn't mean your not micromanaging, or enabling micromanagement as it is usually the line manager using scrum as an excuse to account for every hour in the day. Sometimes that is due to pressure from up high for various metrics to improve, etc. Other times they are just douchebag managers that don't know what they are doing...

Re: You don’t need standups

#337
Probably too late to this thread, but anyway - the key to understanding agile tomfoolery is that processes are most effective if they evolve to meet the needs of the people in the team.

A process will always feel like a burden (and be less effective for it) unless it is co-created by the people right in the middle of it. Most people like doing a good job if they're permitted to, and like supporting their colleagues if it doesn't prevent them doing a good job. Few people want to make their colleagues' job harder or get in fights - much of this is friction caused by bad processes.

Given a chance to talk over problems faced by each team-member and to discover fair solutions, a team that dislikes agile may themselves choose to adopt parts of agile if it is obvious that it solves real problems and makes the team more effective.

The difference between a pointless, painful, morale-destroying standup and a fun, useful, team-building standup is that one is imposed from outside and the other naturally arises from a team allowed to figure out for themselves how best to work together.

Re: You don’t need standups

#338

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…

> I don't find value in anything that agile offers, can I just throw it out entirely by your argument? Yes, of course? But I think you might be confused about what agile is, going by your remark about processes that agile imposes. There are none. Agile is about certain values, and people have come up with various processes that try to incorporate those values. This fails sometimes, mostly because different teams requ…

Then it becomes completely meaningless - It's the equivalent to saying to someone - "Be good" without defining anything about what good-ness involves.

Once you start defining specifically what you mean by good, if your initial premise falls apart and there's no practical way to be good, then what's the point of saying be good?

Re: You don’t need standups

#339

Earlier quoted context omitted.

I really don't get this "management can micro-manage developers". Sounds like you work at a very shitty company / unhealthy environment. Dailies are for the actual working team, so they work better together and not a tool for team externals to shit all over the process. I really can imagine your scenario - do you really have your CEO standing there on your daily meeting? Or are you bothered by your Team Lead? I'm a C…

Without scrum, if a CTO wanted to ask how an individual developer is doing, they could ask their line manager. With scrum, a CTO could just dig in to some of the many dubious reports that scrum generates. They could look at an individuals burn-down on tasks, and compare them across developers/teams. No matter how stupid this sounds, I've seen this exact thing being done by company Directors. Decisions are made. Devel…

You're basically arguing that CTOs mostly cause damage and it's better to hide various vanity metrics from them with the purpose of them not meddling in the process.

My view is that looking at scrum metrics will provide you with additional insight into the development process. I understand that shitty managers will simply take those and decide on top of that. Proper managers would look at the numbers and go ask the line manager what is going on.

I can give you a very practical example - before we had scrum and burndown charts our team leads had limited tooling to detect problems and even quantify problems in the development process. Now we can use that to improve our process with the purpose of us being more efficient and making the development process less stressful.

I never look at burndown charts - I'm the CTO and my purpose is strategic. VP of Eng might look at them, but only if issues are detected, while team leads need to use them daily to help them improve how they work.

Post reply on HN