The engineer did not choose to represent themselves in weird daily show-and-tell meetings. The commit history is there regardless. You could just look at that.
"Stand up" meetings are not hand offs in the ER. Continuous integration with automated testing is.
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.
They just recommended cross-checking status updates in "stand up" meetings with commit history to catch engineers underperforming. That is (1) (2) and (3).
You are not answering my question. No, you ask your acquaintances who work in law, finance or medicine. Neither does academia have any "stand up". What specific needs do CRUD software projects have that are met by infantilizing daily status reports? What needs for daily status reports do these projects have that the Linux kernel doesn't?
What specific needs are met by daily status updates? Professionals outside of software don't do that. The best software projects don't do that. It's very popular in CRUD projects led by non-technical middle management with trust issues.
It sounds like you could just read their code and the meeting was unnecessary. Linux kernel developers are distributed but don't do daily status update meetings.
Daily status updates are not useful. Linux kernel developers don't do them. I trust that nothing is stopping your engineers from having a chat and that their manager doesn't need to schedule their chats for them.
Does French law mandate trial periods or 3 month notice periods? You can usually negotiate those away. Reference checks or trial period but you should really not require both, that's an employer problem.
Europe pays lower than the US but pays better than other regions. There are many countries with low pay and poor labor rights. We should try to have high pay and better labor rights.
Software engineers are not assembly line laborers developing x cogs per hour either. There is no evidence that micromanaging software projects works.
Tenured mathematicians are immune to deadlines, and non-tenured ones don't "story point" conjectures. Your PI does not usually make you submit daily status reports. Targeting a submission date three to six months ahead and trying again if it doesn't work out is a framework that would work in software engineering too.
That attitude works well in other professions. If you want to become a managing partner at a law form you are expected to have chops. Why should software engineers accept micromanagement by laymen?
Forcing every team in the company to use the same project management framework because consultants who never created great software claimed it's a panacea. Interesting decision.
How long does it take to fix a Linux kernel bug? Anywhere from a day to 20 years to never. It's either done as soon as possible, or it's done when it's done and that works for the best software projects.
Estimating is not hard, it's snake oil. That's how you end up paying $100M for burndown charts and a government website that doesn't work.
Technical knowledge should be a necessary but not sufficient condition to become an engineering manager. A layman can't take a two day course with no exam and become a managing partner at a law firm. Why is that sufficient to become a micromanager in an enterprise software project?
That's yearly planning. If estimation means giving your best effort to complete a project over the next year then that's not a problem. When you start micromanaging on a biweekly basis with daily status updates then it becomes a real problem.
How about getting rid of the "stories", "points" and "sprints" altogether? Not only is the nomenclature abhorrent, the best software projects don't use enterprise agile methodology.