Hacker News Reader

Comment by rhaway84773 | Hacker News Reader

I’m not sure why weekly status meetings lost favor.

Meet for 1hr every week as a team, and go over what everyone is working on and see how we’re progressing, and forecast where you should be by the next week.

The moment a developer feels they may not be able to deliver what was expected by next week’s status meeting, they share that with the team in whatever asynchronous communication tool your team uses, whether it’s chat, email, etc.

Regular problems and communications are raised in the same group chat/group email.

It doesn’t matter how small the daily standup is. It could be 5 minutes. But it’s a daily context switching exercise. I think it’s far better to have a single weekly, but longer meeting, so there’s only 1 context switch in the entire week.

View on HN

At most places I’ve worked, long standups turn into “watch somebody else use Jira” meetings that all participants ignore until they hear their names. Not a great use of anybody’s time.

What is supposed to happen in Good standup?

"Any issues/blockers?" ... "No? ok - chat tomorrow".

“Good standup” also surfaces what people are working on because it might be important for the rest of the team to know for innumerable good reasons. It can serve as an opportunity for many-birds-one-stone, or even as an opportunity to interrupt work that doesn’t need to be done because it’s redundant to other efforts or because other efforts made it moot.

But yeah, you won’t get that from standups where people aren’t invested in what others say they’re working on. That’s just people blabbing for a (hopefully short) ritual time.

But why am I waiting for a standup to raise issues/blockers.

Nearly every company has a team chat now. And even before team chats became popular email lists existed.

And if you’re co-located then you just ask your neighbors.

I never have any issues to raise in standup because I’ve already raised/resolved them.

Exactly this. Why should we wait next day standup to discuss blockers? This is non sense.

In the few cases those need some synchronisation, further discussion and knowledge-sharing across everyone in the team, it's a time set for that to happen.

Anything else can be discussed asynchronous, when the need for some synchronisation happens the stand-up is a good way to tackle it in a iterative way. Everyone knows what to expect.

By the way I'm not disagreeing with you, my current team (and the best teams I've worked with) don't need a daily stand-up, just a recurring time slot available for a synch time when people feel the need. People can show up when they want.

Because everyone may not be available all the time except standup when all hands are on the deck. Or maybe the discussion is better done face to face. Or maybe the issue happened just before standup and the timings aligned with standup. Or any of the myriad reasons. The example also doesn't preclude raising issues outside of standup.

"Anything to bring up on those blockers, any help needed? No, ok, next: anything you want to bring up in the work in progress? Ok. Any further topics? By the way, if these topics are not relevant to you, you're free to go".

That's basically it.

The best daily standups I ever had went like this:

Everybody is physically standing up, in a place where there are no computers. Going around the circle, everybody answers three questions:

    1. What did you do yesterday?
    2. What will do you today?
    3. Any blockers?

Any long discussions were tabled until the standup was finished. It took about 5 minutes to get through a team of 6, and was a great way to kick off the workday. On Zoom, you can't get quite the same kind of effect. But you could still keep it short, and you could leave your ticket-board out of the meeting.

I find that the no-Jira standup is better, because it makes people more honest about what they've actually been doing. They don't feel the pressure to fit some kind of Jira narrative, and will instead just talk freely about whatever's on their mind. Much better from a team collaboration perspective.

When I’ve experienced this, I’ve availed myself of my personal favorite cargo cult rule: if you’re not getting value out of a meeting, you can leave.

Cargo culted from Urban Airship, and almost all of their meeting rules have been well received several places I’ve introduced them. Although admittedly in my experience this particular rule is best invoked with some extra social subtlety.

1. Thats no longer a standup but a planning meet

2. Those participants are not good employees then and should be told to pay attention or face further action. Meetings are for everyone to get on the same page, I’ve had too many engineers who think they have better things to do then implement things wrong or ask questions we covered in the meeting. Not something I’ll deal with anymore.

If one of ten employees isn't paying attention in a meeting, good chance it's the employee's fault. If most of the employees in a meeting aren't paying attention, it's probably the manager's/meeting-runner's fault. In between those, it might take some digging to figure out who needs to adjust to fix the problem.

> I’m not sure why weekly status meetings lost favor.

Likely because, at least in my experience, they suffer the same problem as daily meetings: They provide no value. If you aren't already in the know about status before the meeting comes around, you didn't care about it in the first place and won't magically start to care when the meeting is in progress.

Those who have meetings for the sake of process adhere to daily status meetings because that is what the process literature suggested to them. Anyone who questions that further questions what is to be gained by having them at all, leaving little in the way of middle ground.

I've seen 1hr 11am weekly status meetings turn into "does anyone have a 1pm?" as Sr managers drill into every developer over the minutia of their status reports. Single handedly the most unbearable meeting series I've ever attended.

At least standups have structure and they are "supposed to be short", which helps a lot in keeping managers nitpicking at a minimum. Open ended 'status meetings' are horrible. A weekly 1 hr "standup" with a "no managers are allowed to speak", "stick to what you did, what you'll do, what are you stuck on and need help", isn't that bad, but you have to have structure.

Plus, if you are doing "Scrum", in a retro you should be able to suggest just having a "mid point" sprint review and change the process. I realize that's easier said then done, but its a good smell test on your org's attitude towards their process. Just make the suggestion and from the reaction you can tell if you can change the process like you are "supposed to".

This is a problem with the manager then.

As far as I know, there's no such role as "manager" in a Scrum team.

The Scrum way of working is a joy, which I have gotten to experience in my career just once. Practically it also seems very difficult for an organization to support, at least many have failed.

Scrum teams need to be autonomous, or the process becomes torture. Scrum as a process is rather simple, but the context is exactly a team working on their own. SAFe and such seem more like consultant slideware to me .

> Meet for 1hr every week as a team, and go over what everyone is working on and see how we’re progressing, and forecast where you should be by the next week.

So you're spending longer and getting less accurate results?

> The moment a developer feels they may not be able to deliver what was expected by next week’s status meeting, they share that with the team in whatever asynchronous communication tool your team uses, whether it’s chat, email, etc.

What prods them to think about that though? Often there's no clear threshold, and if you're supposed to keep it on your mind continuously then that's taking away from your capacity to think about what you're building. Having that daily sync point to take stock is very useful.

> It doesn’t matter how small the daily standup is. It could be 5 minutes. But it’s a daily context switching exercise. I think it’s far better to have a single weekly, but longer meeting, so there’s only 1 context switch in the entire week.

I mean hopefully you're switching out of work context when you go home or go to lunch. It's a tradeoff, but a few minutes a day isn't so intrusive IME.

Weekly isn't terrible, but I'd look at it from the other side: how long is it ok to be blocked for before you want to make sure you remember to raise things? A day works best IME. Maybe even twice daily would be better.

You don’t wait for the meeting to raise things. You raise them when they happen. We have enough async communication tools that you can raise issues without having to wait for a meeting, and yet without disturbing someone who may be focused on something specific.

Really easy to thrash at something for days though thinking you are ‘almost there’. And someone else on the team might be able to help either directly or help you think of the solution if you just spoke out loud with the team sharing information.

> I mean hopefully you're switching out of work context when you go home or go to lunch. It's a tradeoff, but a few minutes a day isn't so intrusive IME.

I don't think that is what was meant by context switch persay. It's like reading a fiction book, the context is the story. If you put that down, you might have to come back and re-read the last few pages to remember where you were exactly.

Worse yet for meetings, personally, about 15 minutes before I have to stop doing mostly anything so that I'm not too into it to then be late. About 5 minutes before I literally do stop everything otherwise I'll get into something and look back at the clock and it'll be 3 minutes past the hour.

A productivity hack I'm trying is to set an alarm for a few minutes before a meeting so I can do this more reliably without so much of a context switch.

All in all, given about 10 minutes before the meeting it is intentionally doing little so you can click that button on time, and then there is the time needed to get back into your work (most literature says it takes about 20 minutes to regain programming context), any meeting costs about 30 minutes of context switch overhead. It's a lot of time given a 8 hour work day.

Reply on news.ycombinator.com