Talk to your team. Give a shit about what they're doing. Care about your work. Care about your project.
Sometimes heavily scrutinized, reasonable process doesn't need to be modified. Sometimes the devs do.
I think this is the crux of many problems plaguing software development today.
Unless you're at a brand-spanking-new startup or have been handed the keys to an exciting greenfield project, you're going to be on a legacy project. Which means a combination of adding new features to a pile of cruft, or fixing bugs in that pile of cruft.
This is where it becomes problematic: no one stays at a company longer than a year or two. Industry compensation does not work in the favor of the person dedicating years to a single company and/or project. Which means there is a built in don't-give-a-shit factor to every software project today. Not that the rockstar coders of yesterday ever gave much of a crap of the quality of code they left in their wake, but industry incentives turn us all into code monkeys. And if you happen to be the guy or girl that cares and is staying at the company many years, you'll surely witness a parade of ladder climbers come and go and absolutely destroy the quality of your hard work and effort.
I could go on about title inflation, and the fact that only about 1 in 5 devs is, in my book, truly a senior today. But we're way off topic now.
If you go to the original agile manifesto, it’s basically just this. It’s consciously against packaged, branded solutions.
I’m fond of Scrum. The most coherent and comfortable jobs I’ve had used Scrum. Also one of the worst (in terms of productivity) tried it too. It seems to me that the overall system can be a problem, but it wont be the whole story. Sometimes the client/product/management sides of things lead to counter-productive work. Sometimes developers silo themselves, or think too much about their code and not enough about the product & users. Sometimes the product sucks.
It seems to me the hardest bit is defining, scoping and agreeing the units of work, appropriate to the size of team and aims of the product. If you get this wrong, the product will suffer. It takes some input from everyone to get this part right, and you can make it work with any system, branded or not. It’s just hard. I’m not saying you need reps from all departments in all your meetings, I’m saying you need everyone to work within and around the framework in a way that gets the product made.
EDIT: type.
There are lots of people who benefit from a named manager. Expecting people to self manage who don't really want to is as bad as micro managing people. I know because I f'd this up at least 3 times building my last company. ;)
I think people check out in synchronous standups just as much as in async ones. The only difference is if later I'm interested, I can go look it up if it's async.
That has been my experience, too.
Going async sends a message that people don't need to care about what their team members are working on. That's a dream come true for the people who just want to pull Jira tickets out of the queue, finish them in isolation, and then collect a paycheck.
However, it doesn't make for great team cohesion and knowledge sharing. Teams end up compensating with extra meetings and coordination overhead, which starts to defeat the point of async standups.