What are you supposed to say then?
Daily is way too ofent to have anything interesting to say. It is a low effort way for the manager to keep track on things and make people feel stupid for not doing progress in the maner the agile scoreboard dictates.
Daily stand-ups are for coordinating with the other devs. E.g. "It will take a couple extra days to do this backend API that you are waiting for", "I'm a bit stuck, anybody will have free time today to pair program?", "Who is able to drop their low priority task so that the high priority one gets done on time?"
If you're on track and don't neet anything, just "no updates today".
The first 25 years of my career as a programmer we never had daily stand-ups, had never heard of them. We shipped.
Something about all the "process" that has crept into the job over the last decade or so has really turned me off.
Seriously, it was only "main" when I started at Apple 26 years ago. Our version control was such that when someone wanted to edit a file it was "checked out", locked to others on the team, until it was checked back in.
It worked surprisingly well (obviously no merge conflicts for one thing). I doubt anyone would suggest going back to something as simplistic (but I have to admit Git feels way too complicated than it should at times).
There's a huge difference between a "daily progress meeting" and "sensible development". I too have seen a lot of process creeping into things and I'm glad I'm getting close to retirement.
"
Why do you need standups for this? They should talk to each other directly.
I have been to a team where X would need help on something that Y has solved in the past, Y does not care to listen in the standup and volunteer to help, and i had to ping him “Hey Y you have resolved this in the past, care to help X after the standup?”
Shitty standups go bidirectional ways. Managers can make them terrible, but devs can do that as well.
Which work orders? Which PRs? How much progress? Are they harder than expected? Easier? Any blockers? Anything that could help?
Standup isn’t just for managers. It’s for ICs to also communicate their needs, obstacles, concerns, or even just give everyone a heads up that a certain task is more difficult than expected. If you’re just searching for the bare minimum to say to get your manager to move on to the next person, it’s a waste. It’s only a few minutes, so take advantage of it for some quick bidirectional communication.
Tackle: I'm going to block. No blockers (err).
Tackle: I'm going to block. No blockers (err).
Guard: I'm going to block. No blockers (err).
Guard: I'm going to block. No blockers (err).
Center: I'm going to snap the ball then block. No blockers (err).
Running back: I'm going to run. No blockers.
Wide Receiver: I'm going to run then maybe catch the ball. No blockers.
Wide Receiver: I'm going to run then maybe catch the ball. No blockers.
Wide Receiver: I'm going to run then maybe catch the ball. No blockers.
Quarterback: I'm got to receive the snap, then do something with the ball. No blockers.
Tight End: I'm going to block. My blocker is that my shoe is untied.
Guard: You should tie your shoe.
Guard: You should tie your shoe.
Running back: You should tie your shoe.
Quarterback: Would you guys STFU, we've got stuff to do.
Tackle: Daily standups are important for morale and communication.
Referee: Delay of game, 5 yard penalty, repeat the down.In other words, if you have plenty to talk about in your stand-ups then you are doing something wrong. Which is the point of Scrum, this fixes communication issues, but your team really shouldn't need this.
Yes. The other difference is that football has absolutely nothing to do with software development whatsoever, so why organise as a football team, that just seems like a bad joke to me.
If only this we're always true. In reality your teammates can be busy which means queries to them will often go unanswered. Standup is the only time to guarantee responses from busy people on the team.
So it's basically impossible.
Whenever someone says "This [meeting | standup] could have been an E-mail!" I respond "So do you read and respond to your E-mail?" I love asynchronous, but the entire team has to put in the effort to make it work.
If the only time ICs communicate any of that stuff is at a set time each morning, then something is already seriously wrong.
Agreed, It's much more productive to simply approach some of your coworkers, or write in a team chat after the daily. Mentioning problems in the daily just adds pressure and stress with no benefit.
The ones we already discussed were in progress. Did you expect it to magically change overnight?
> How much progress?
Paterio already went over this with you. I am 80% done. Tomorrow I will be 80% though the remaining 20%. The next day I will be 80% done with the outstanding 20%.
> Are they harder than expected?
Yes. It would be far easier if you didn't interrupt me.
> Any blockers?
If there were, and I haven't already told you, why would I tell you now?
> Anything that could help?
Not bothering me until I am at a stopping point.
--
What's the purpose of the standup again?
We are talking about daily standups. In all likelyhood, you don't encounter blocker that often. If you have frequent blockers, then you have larger issue. In most days, I don't need help at daily standup time. If I needed help, I asked before and did not waited for standup.
> Are they harder than expected? Easier?
What would that be useful for? Like, I do quick venting sometimes, everybody does, but I am not under illusion it is useful for others.
Sometimes things progress without any surprises or blockers. A meeting just for the sake of having a meeting seems like a waste of time and effort.
A plain old developer, who does not manage other developers.
On the other end, having to report things based on a timeframe that tight relative to the work done will quickly devolve towards finding things to report on, no matter how unnoteworthy. Teach people to speak up and show noteworthy things instead and have a bit of faith in your other metrics and report pipelines.
Nobody does this, they do it immediately, at least all the places I've worked. I need help, first I try to figure it out myself, then when I'm stuck or want to make sure I'm doing it right, I ask the owner of the code I'm working with. This makes standups not only redundant (information has already been shared) but distracting.
>But, I do see the point of a daily sync up for team building, especially for remote teams.
I've found it to be a morale killer more so than a morale booster. Fuck I gotta stop what I'm doing for this stupid standup, or I'm not gonna do anything because the standup is in 45 minutes; I'll just get distracted.
I was once at a place where you actually stood up and the standups were 45 friggin minutes long. Total waste of time and I was so demoralized after it took me 30 minutes just to decompress and get stuff done.
They would be slightly better if done on M-F-W or even more so on T-TH. Once a week meetings for about 30 minutes with biz then 30 minutes with dev works great for our team.
(d) creates a daily source of anxiety for developers who doesn't handle public speaking well. Which is a lot of them, but it is a shameful thing to admit.
Instead I see someone who questions the utility of this particular daily ritual. If others on the team feel the same way then it's more like they're calling the emperor naked.
Also see you working on one large project or a bunch of small projects ?
There are no bad teams; only bad leaders. -Jocko
Took me a long time to buy in to this but it's 100% true. Sucky standups are the direct result of an ineffective leader - whoever that may be.
And it makes sense- even if the team is "objectively bad", a good leader will help transform them.
They will only do them if they're dictated by the company, or the the team members are unable to work and communicate independently and requiring constant micromanagement. The latter is usually a case when the team members are provided by the outsourcing company, or they're some kind of "team extension".
I agree with your sentiment that it's a problem of skill and motivation - but that said, the usual problem to solve with any process is: how do you make your day to day operations as efficient as possible given the level of skill, codebase quality and motivation you do have, not the one you want. Developers (on average) are only average. Code bases aren't great. Motivation will vary.
So it's a chicken and egg problem. If the reality is that the developers are tired underpaid undersupervised and undermotivated. All that could change, but it would take time. The process happens now.
Addressing standups as the sole issue completely ignores the holistic factors that influence the outcome. If a team is bored, undercompensated, overworked, undersupervised, then they're going to deliver shitty standups, and those standups will be a waste of time. When the participants are eager to provide a handoff of knowledge and prompt eachother for interchange, then you get the good standups that leave people racing back to their desks to build off of that synergy.