Live data from Hacker News

You don’t need standups

medium.com

261–270 of 341 posts

Re: You don’t need standups

#261
post #238

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…

In my experience, at least at bigger companies, standups are there to justify the project manager’s job. It’s for them to tally that everyone is doing their work. Simply, they see that the team wishes to meet for development purposes and it gets co-opted into a status meeting. I find that small business gets it right more often because there is simply less bureaucracy and developers are much more trusted.

Feel free to send them this way. I’m currently working at a startup where the CEO is the product owner/manager, as well as doing all the CEO duties. A good PM would be a dream come true right now.

Re: You don’t need standups

#262
It seems that much of the discussion here can be distilled into not trusting people. Lack of trust that people will work, can do the work, will tell someone when they have a problem or surprise, and mistrust of the effectiveness of the particular Task Management System in use.

Daily standups as largely practiced today, are a means to overcome this lack of trust through micromanagement.

Re: You don’t need standups

#263
post #149
post #108

Earlier quoted context omitted.

Maybe not, but if your peer said "hey can someone help me with this task" in a standup, wouldn't you want to help them once the meeting is over?

Replace that with asking for help in slack or whatever, and you don't need a standup. And you also get help as soon as people's time is available, not the next day.

I've found that asking for help over text or the phone is less effective than asking in person.

Re: You don’t need standups

#264

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…

Could not agree more. This coupled with the feeling of being "defeated" when you need to move cards from this sprint to the next sprint just because you didn't get it completed is why my team went away from sprints.

Re: You don’t need standups

#265
We actually massively profited from implementing standups and agile-ish process and we really do not feel the downsides mentioned in the article.

Standups:

1. The standups are held in very small groups that work on the same thing and where it is important that they are coordinated.

2. Standups are not a place to discuss priorities. Those were set way before. It's for you to tell everybody what you're working.

3. Standups take 5-6 minutes per day. It's less than one foosball game. Some teams actually do their standups while doing a plank, so that they're very short.

4. Standups help us achieve team cohesion. Everybody knows what everybody is doing, so people can help each other when needed + leads can detect issues sooner (especially valid for introverts, since they sometimes lock up and grind away without telling anybody).

5. If you're bored during standup and not getting any value then you should not be part of the standup. Standups are considered optional, but everybody attends.

Agile process:

1. 14-day scrums are to sync priorities and discuss the development process. Generally speaking, we set up quarterly goals (and we have a rolling forecast for the next two quarters) so its clear what people need to do. We do not change the quarterly goal, except if external forces force us (example: things failing).

2. The schedule also gives the leads a clear tool to block any "non-urgent" but important tasks that would meddle in the development process. Instead of caving under the pressure of product teams or high-level management they can clearly state when they will start working on the task. I think the schedule needs to be set so that management can handle the lag between request and start of work on the request. I've heard of 3-day sprints since that was the most effective way of blocking daily priorities changing until management got on board.

Re: You don’t need standups

#266
post #209

Earlier quoted context omitted.

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

I wish everything was so simple. At a past job a very technically strong coworker spent months on a problem and eventually threw the towel and handed it to me. It took me another couple months to find a reasonable solution to it. Some problems are _really_ hard and no amount of help will get a dev to solve it faster.

But if I hire nine women, I can get a baby in a month right?

Re: You don’t need standups

#267
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 are great even for on-site teams. First, people only spend half a minute to post it; manager needs half a minute to read it to know whats going on. After it is posted, everyone have something to refer to before the weekly meeting, which does not have to be long if it is well prepared. The set up keeps the communications efficient and consistent.

As for the original post, the outstanding team does not need the manager, so far. It will need one, after the writer deteriorate the culture and communication channels that have been established before him with own "trust" and f-words.

Re: You don’t need standups

#268
This approach works really well when you have a great team - like I'd imagine palmerj3 has at Spotify. I've worked in a few of these places and know how well this approach can work. However, I am currently working at a place with people who are very inexperienced and frankly pretty lazy and just generally not very motivated. The manager has to constantly monitor them and make sure everything is being done. In this type of environment you just wouldnt see the end result at the end of the month. But personally I find this approach works super well for me.

Re: You don’t need standups

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

Goal for today - get stuff done. finish up things we planned for the week.

Blockers - hopefully blockers are identified and communicated right away vs waiting for standups.

How to get stuff done - less unnecessary meetings and processes. Async communication.

Re: You don’t need standups

#270

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…

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 CTO and I've never been on a daily. I don't care about daily tasks. I care about shit breaking. It can be our tech, our infra, our people, etc.. That's what I need to solve. I don't get it why in the god's name I would attend a daily. What value would I get out of that?

If on the other hand, I see shit going down, I dig in right away and talk with the Lead and/or Team if shit got real.

Post reply on HN