Live data from Hacker News

You don’t need standups

medium.com

311–320 of 341 posts

Re: You don’t need standups

#311

Earlier quoted context omitted.

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

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

I think that's a management problem you'll run into with any development methodology you use. There are a lot of management types that slavishly focus on metrics whether or not they make any sense, and they can do tremendous damage to any organization.

Give those people a tool and they'll find a way to misapply it, whether it's velocity, or performance reviews, or LOC, or whatever.

Prime example of this was stack ranking at Microsoft. How much productivity was lost due to the political maneuvering and backbiting caused by their misunderstanding of bell curves?

Re: You don’t need standups

#312
post #261
post #238

Earlier quoted context omitted.

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.

PMs have a role, no doubt. They should help facilitate discussion and help protect the team and communicate upward, and provide guidance where necessary. I have worked with some that did this well. I have also worked with some who cared so much about status that it negatively affected the team because they wanted five or more meetings a week (even stand-ups took an hour each). This type of disruption isn't limited to PMs, of course, it's just something I've found in my experience -- more-so than any other role.

Re: You don’t need standups

#313
post #283

Earlier quoted context omitted.

> The rest of us met every morning for breakfast. No standing up, no meeting. But we knew what we had to cover in between shooting the crap. We did well. He did not. Basically, since the other guy did not wanted standup you intentionally left him out of loop and communicated only among yourself during breakfast. If there was ever ugly politics, it is this one. > He finally came. Every morning the team would have fun…

Maybe they were being toxic, but it simply seems like they took a little time in the morning to go over things and he chose not to join them. So what should they have done, each staged separate little talks with him to go over everything that was discussed in their morning meetings? Compile meeting notes and send them to him? It doesn't sound so much like sabotage as it does that he chose to put his head down and esc…

No, of course not. "We are having coordination meeting at " announcement is already fine. Just starting standup when everyone is in office even if he disagree is fine too.

The time and place here seem juuuuust coincide with time and place he is least likely to be at. Standups are not supposed to be passive aggresive way to enforce early coming to work either (most coders have flexible time, your process should honor that) nor are they supposed to prevent you to have breakfast with familly or alone in home.

And yes, if collegue does nor know info he needs for work, I would tell it to him even if he clearly missed it by his own mistake. I would also tell him that he don't know info because he ignores meetings he should be at. Transparency and open discussion, basically.

Otherwise said, you solve it like any other disagreement over something that requires coordination.

Re: You don’t need standups

#314

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…

> I don't want to have to say "Yup, still workin' on those bugs" every morning. Then don't. Give specifics about what you did, what you accomplished or didn't accomplish, and what your next steps are. Provide evidence of forward velocity, or ask for help if you're stuck. The key here is accountability. Don't be "the guy in a room" who doesn't apprise the team of what's going on in his world. That guy is first in line…

I find it interesting how literal people took that.

Must I have provided a lengthy, detailed example of what I would say at a standup? I'm the guy who pushed for people to provide more detail at standup. I thought I'd communicated my point and didn't think it a particularly good use of my time or anyone else's to spend more time on that sentence. Now I regret writing that it at all.

If anyone manages to read this, keep in mind that I was not suggesting that a professional update along the lines of "d'uhhh... i did a thing" is particularly valid.

Re: You don’t need standups

#315

Earlier quoted context omitted.

Screw these other commenters saying you're a stubborn introvert. If I had a company, I would hire you. I have the same view. Micro management erodes trust, which deskills programmers. If you know the exact bounds of what a programmer that you hired can do, then they can never do anything exceptional. I understand large companies need reliable workers because they are working on cornering their market, but for startup…

It's not micromanagement. It's working as a team. I don't really understand what you're saying. Sometimes programmers are proud and don't want to seek out help. They'd rather spin their wheels trying to debug something than stoop to asking someone else for help. It's dumb but it happens.

If the team is truly a team, that kind of goal-oriented facilitation really isn't necessary. While it's good to have some sort of institutions within a team, good quality teams tend to be self-organizing. If employers focused more on creating quality teams, they wouldn't need tools like Scrum to mitigate problems that might not even exist (the fact of which can easily be swept under the rug by rigid adherence to such systems).

Sometimes I run into a really tough problem, and good team members don't need to have a system to force this behavior. In fact, I'd say it's within the prerogative of a developer to withhold problems they believe they can work through so that other cooks don't jump in to crowd the kitchen, and so that managers don't make a counterproductive decision to dislodge a perceived roadblock.

As you say, some programmers are proud and don't want to seek out help. Does this reflect in their work? If it doesn't, then who cares? And if it does, then management should resolve the issue by whatever means necessary. Trying to force "I'm facing a tough bug" out of people is not the way. Creating a culture that fosters collaboration, on the other hand, seems more effective in getting people to seek genuine help.

Just make standups about the people. Hire good engineers or engineers with potential and invest in them, and allow their team to function naturally. Remove the goal-orientation from standups and just give teams 10 to 15 minutes out of the day to just shoot the shit. Having to make it about going person-by-person and saying "Yesterday, I did X...", "Today, I'm doing Y...", or "I ran into some issues with X-thing", is really just like being back in elementary school where the teacher picks on students. I know some people don't seem to feel this way, but I'm really not that interested in going back to the 3rd grade.

Re: You don’t need standups

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

ah the black hole programming movement! We've been there with "waterfall", which was a disaster. Not explaining and sharing is counter to working on a team. If you are a one man army, and no one knows what your code does, or if it can be compiled or deployed without errors, then that is bad for your company.

Re: You don’t need standups

#317

Earlier quoted context omitted.

There isn't. Raising an issue without ever fixing it is very demotivating and causes a "fuck it" attitude.

Everyone being aware of an issue without it ever being raised or acknowledged is equally demotivating and results in the same attitude.

Same thing. Issues that are known and don't get fixed are demotivating.

Re: You don’t need standups

#318
post #229

Earlier quoted context omitted.

#2 never happened at any job I've had. It was always the entire team and we all had different projects. Sometimes entirely different applications.

That sounds like you were all on different teams, in the sense being used here, and probably shouldn't have all been in the same standup together apart from maybe a once-a-week catchup.

A friend worked in a startup where 20-30 people of the tech dept. had a hour long standup. QA, sysadmins, developers - all had their 2 minutes to essentially do a daily status update.

I'm glad I haven't lived through that hell.

Re: You don’t need standups

#319
post #292

Earlier quoted context omitted.

It's not micromanagement. It's working as a team. I don't really understand what you're saying. Sometimes programmers are proud and don't want to seek out help. They'd rather spin their wheels trying to debug something than stoop to asking someone else for help. It's dumb but it happens.

I'm not GP, but let me try to explain. The key is to treat people as responsible adult professionals with the best intentions. This way communication will happen organically and proactively. For organic proactive communication async channels are ideal. When you bump into a problem you need help with you message someone you think can help. They will eventually see your message and find the time to reply (seeing and re…

Developers come in all shapes and sizes. Some barely use Slack and are laconic on standups.

The whole Agile (tm) is a surface treatment for having a grasp on complexity. It's more of a ritual thing than an exact science.

The introvert developers are sometimes so introvert and protective that they deliver at the last possible moment stuff that doesn't follow any conventions set by the team and in some cases makes stuff explode after merging.

I would rather have them forced to give me an update and subsequently a pretext to get a peek at their work under the guise of helping than have them fail the whole team. Eventually they shed their impostor syndrome, or at least I hope they do.

Personally, I've been on both sides of this pattern and I would rather still have standups.

As for supervision, I've seen teams selling bullshit with glitter on standups if there were transitional people or stakeholders. Then it's nothing more than the usual status update dance.

Re: You don’t need standups

#320
post #318
post #229

Earlier quoted context omitted.

That sounds like you were all on different teams, in the sense being used here, and probably shouldn't have all been in the same standup together apart from maybe a once-a-week catchup.

A friend worked in a startup where 20-30 people of the tech dept. had a hour long standup. QA, sysadmins, developers - all had their 2 minutes to essentially do a daily status update. I'm glad I haven't lived through that hell.

Wow that sounds like a nightmare. My standups have almost always been limited to just one team, usually 5-8 people.
Post reply on HN