In some sense, standup is a nocebo, a mood killer for me. I am there, in the morning, ready for work, my mind firing up, geared towards working the problem, but no, I have talk and listen about something unrelated. It's like going to a movie and having to suffer the trailers for other movies first.
(There was also this funny psychological research that showed that when you tell someone you will do something, you're less likely (less motivated) to do it. Not sure if true, but if it is then standups alone have caused billions of loses in productivity.)
In any case, I think the discussion about individual productivity is somewhat sidetracking the core issues. What I wrote applies to the whole team as well. In my experience, the best design decisions come from individuals working alone, understanding the problem, and then these design decisions are vetted (and possibly changed) by everyone in an open discussion. This cycle can happen on almost any timescale, depending on the nature of the problem. So one doesn't need to be in an ivory tower for this to work.
Timeboxing as such is not a bad idea. But I think conflating it with "being done" is just wrong.
They do have their benefits though, especially when well run. A team member may encounter something they're having difficulty with that another developer has encountered and solved in the past. You might want to share a problem you encountered or findings that are relevant to others.
I suppose that most of those things could just be done as a slack message. Sometimes I feel like a meeting helps ideas flow better though. There's been occasions where having an actual verbal conversation with the team has yielded better results than a slack conversation would've.
Either way, I've never had a huge issue with them, as long as standup is the start of my working day and not like 10 AM or something where I'm going to get interrupted.
IME this has been the biggest boon of standups. If they are kept short, and further conversation is done outside the meeting, they are a good way of matching your problems to other people on your team who may have a solution.
> Sometimes I feel like a meeting helps ideas flow better though.
I generally prefer when protracted conversation/problem solving is taken up between the concerned parties after the meeting, as otherwise the meeting drags on for everyone else who doesn't really need to know about your particular issue. But I do definitely agree with your assessment that "actual verbal conversation[s]" are better for me with regard to figuring a problem out.
But don’t you dare try to have an open discussion at a stand up meeting. The moment a useful discussion starts the scrum “master” will tell you to schedule a separate meeting to discuss it. Honestly, that just kills the flow of communication. I have never scheduled a separate meeting to continue the discussion. We just end standup, go back to our desks, and don’t talk to anyone.
Have you considered that if this didn't happen, it would be one of your co-workers on this thread, instead of you, and they'd be complaining that:
"Our scrum standups are supposed to be 15 minutes long, but they always take an hour or more, because people start going down some rabbit hole that doesn't concern half the team, and the scrum master won't politely interrupt and ask them to schedule a separate meeting. So much time has been wasted by this that it's unbelievable."
I have never scheduled a separate meeting to continue the discussion.
Why not?
That can be hard -- many / some people would be worried it'd be impolite to leave and in a way say "the things you're talking about aren't interesting to me".
And they'll stay and feel frustrated, in silence.
The result has worked almost exactly as intended: there's breathing room to discuss issues or ideas that come up in the course of conversation, but discipline around keeping those conversations brief enough to stay on the rails.
IMO at previous companies getting told "this isn't the time for that discussion" really frustrated me. As the OP stated, these conversations never happened, and it's healthier to allow some time and space for people to talk off-script when they're all meeting together.
It's how Lockheed let Kelly Johnson run the Skunkworks however he wanted to. Johnson delivered the impossible again and again, and Lockheed was smart enough to not interfere.
Some people can be brilliant at something while at the same time being toxic, with the toxicity ultimately winning. Kalanick at Uber might be an example.
However, while the combination of autonomy and brilliant personality might be a prerequisite of outstanding success, I'm not yet convinced that it's an overwhelming indicator of it. I believe that a brilliant but toxic personality with autonomy can lead to an ultimately fatal instability.
I've given up trying to estimate how long a task will take and more or less just pick an arbitrary (usually comfortably large) number of points.
The thing is, it isn't even about estimating the scope of work, which is often unknown until it's complete, especially if I'm battling technical debt. A given task might take me an afternoon on a good day, or half a week on a bad week. Case in point, I got more work done on Monday than all of last week. That's the joy of having ADHD I suppose.
At least my manager is very understanding, and recognises that on a macro scale I get a lot of high quality work done. I think that's the key to being a good manager, understanding that your subordinates have different working styles and managing them with that in mind. I'm sure there are "10x developers" out there who work in a more consistent manner, or benefit from more hands-on management than I do.
My guess would be that the 10x-ers have are independent enough from any given employer that they can reject Scrum even if everyone else has to follow it. And later on, their ability to work on their own terms is what then makes them 10x more productive than the poor scrummers.