> Why have they reported at every standup the last six months
Every what?
Every what?
Yes, having a chat between the team for fifteen minutes every day is in fact quite useful, believe it or not.
We're not talking about hour long waterfall-y management progress review meetings here.
You could use the same logic to claim that "issues and PRs are not useful" because the Linux devs use a mailing list and patches. I think that's obviously absurd, all that this example shows is that a mailing list and patches can be a useful way to develop programs. It says nothing about alternatives at all.
How do you know this? Have you done an exhaustive search?
For one example, are you quite certain that no part of any military ever does this?
What about every factory?
You are assuming (1) that standups are status updates, and (2) that they are scheduled by manager, and (3) for benefit of the manager.
In the last several teams I’ve managed, it’s the crew that has encouraged meeting daily, and in the standups they are mainly talking to each other. It’s where they cover hot topics and bugs for the day quickly, with the fluidity of spoken conversation instead of Slack, and also there’s a non-zero amount of friendly casual conversation.
Don’t force teams to have standups, but also don’t assume a team won’t like it.
If you ever move to management, you'll see that as lovely as it would be if every hands-on developer was an amazing and super-productive engineer writing high-quality code and delivering tons of value , the reality is that most teams have one or more people that are struggling and aren't getting much done, but aren't forthcoming about it. They'll represent their work as very challenging (which it is, to them), meanwhile others on the team are objectively better and faster at figuring out solutions and not getting stuck, and they understand the codebase better, and the architecture, and so on. The manager has a duty to spot when this is happening, and engage with the engineer immediately to figure out what's going on and try to help them.
Engineer managers should themselves be strong engineers (and in every company I've worked at, this has been the case up the senior leadership chain), so that they can form a realistic, fair, and reasonable assessment of whether there's a discrepancy between how an engineer represents their work, versus what is shown in the actual commit history.
What, and I mean this in the nicest way possible, the everliving fuck are you talking about?
Professionals do this constantly. Go sit in an ER and watch the hand off between shifts. Go see any serious manufacturing facility and see them review daily everything that happened the previous day. Go see an effective sales org in action.
The scrumbags may have ruined software, but that certainly isn’t the world.
You make your not entirely unreasonable points sound like the output of a zealot.
Why are there no laymen agile coaches at law firms, and no "today I did this, today I did that" breakfast meetings in finance, or in CS academia? Other professionals don't accept this kind of infantilization.
But while every team member talks about the difficult bugs they’re facing, sometimes the actual code tells a different story and can reveal that a team member is struggling to get working code together in any reasonable amount of time.