Hacker News new | past | comments | ask | show | jobs | submit login

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 interested in your status then you're just burning hours.

Also a standup with 40 or 50 people is just plain silly. I worked in gaming a few years ago and our standup was a full game team, the artists, designers, QA, server-devs, client-devs and our stats guy all spoke. It was a bit interesting to see what artists were doing but totally unnecessary for me to hear anything anyone said except the two other people I worked with, and we communicated well outside of the standup anyways.




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


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


If your goal for the sprint is "build widget" then your goal for the day should be "build part 3". You don't change priorities each day, you change how far along you are and where you expect to get to.


The term "Sprint" makes me cringe, it's meaningless in my experience. It doesn't effectively identify goals or deadlines. It's a stupid techie/hipster term that no one apparently pays attention to.


> The term "Sprint" makes me cringe,

Tried that once as a team. Then it became a derogatory joke word, haven't sprinted since. Well only in real life when playing tag with my kids.

Estimating, delivering on time, working together, can be hard. Someone deciding to rename it with a new label, doesn't usually solve the problem, though now everyone has a new label to make fun of.


If you're doing kanban and work in an environment where product direction changes quickly, then definitely this.

If your standup can be replaced with everyone posting on a slack channel, then it's just a status update as there's no discussion and alignment happening, which are the valuable parts.

Most teams should experiment with their process more.


The standup should be with the people on the current sprint. Alignment should have happened in earlier planning stages. "Discussion" is (should be) highly structured in a daily standup and any discussion that is like a dialog should be placed in the parking lot until the meeting ends, when only those interested in that discussion need to attend.


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.


Though what you are doing today is a direct result of what happened yesterday.


My team is about 8 people, but we work on about 15 projects, some with about 3 FTE, some take up a few hours per week of one person on average. It happens that someone works on a project on his own for months at a time. There is some shared tech between them, but also a lot of specific stuff.

I thought that was the kind of situation he meant, where people zone out because they don't work on that project, but who knows.

You shouldn't assume too much about the environment other people work in.


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

This would be better solved by hosting specific IRC channels for those roles and having occasional role-specific meets/lunches to introduce new people.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: