That's useless because everybody else tunes out. Nobody cares what debugging methods you tried on some project they've never touched. If you need help you can just ask somebody.
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.
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.
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.
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.
I think that's either a team culture issue, a management issue, or a business culture issue. Teams I've worked on have had no issue brainstorming ideas for a person who's stumped.
Now, I'm not totally defending standups here, I've been on teams where daily standups are a stuffy formality, and they are miserable. I've also had the pleasure of being on teams where weekly standups were implemented, and they were an absolute delight and completely useful.
I will qualify all of my opinions with the fact that the best teams I've worked with implement Kanban, so there is no sprint planning. We just pull off backlog and work with weekly standups. There's way way less overhead, with some tradeoffs.
I also definitely think that certain team cultures are completely incompatible with standups, to the point that you receive negative benefit from implementing them. If you have a lot of people who are of the type "my responsibility ends where my story points end", I am pretty sure you will end up have a bad time doing standups.
In some previous team, I realized that some people working on very long tasks just gave bullshit updates. What they explained was interesting, it gave a sense of progress, and they communicated well.
Too well perhaps, their small talk was on super minor or even unrelated stuff that they saw the previous day.
They were doing mainly exploratory work, and it made no sense to bring on board other people before they settled on a direction themselves.
I think ultimately a one size fits them all approach only “works” when the people on the fringe also play the game and bullshit (in a good light) their way around.
It's a trade off. Some of the communication is very valuable, and needs to happen for coordination, knowledge sharing, etc. The potential harm of that communication not happening is great, the risk of having a meeting go 15 minutes longer is worth trying to avoid (hence the article) but much smaller.
However, if only some people speak that can create divisions in the team, or make it look like the speakers are the leading members when that may or may not be true. So to prevent that dynamic everyone says something, and people can help the team function better by coming up with a nifty one minute oration.
Ultimately making software is a human endeavor. Sometimes a little small talk prevents the humans from feeling bad and not making software. Sometimes it has the opposite effect.
The best managers figure out which case is true at a specific time and place and adapt. Good managers just have to pick what risks to take and live with the outcome.
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.
Don't wait until the standup to ask for help if you don't have to.
I'm also confused why OP is having standup eith people who havent even heard of the project he's working on. Doesn't sound like he's working on the same product as the other developers.
The standup should be the place of last resort for bringing up barriers impeding a task. The more resourceful you can be at solving a problem/brainstorming outside of the standup the better ime
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.
But you are in the same team in all the other senses, mostly that these are the people you work with in the long term. Some projects you do alone, some with Bob, others with almost everyone, but the team members want to feel like a team and have an idea of what everyone's working on.
