> Doctors do something not far removed. It's really important to them to caucus on case management.

Maybe, but it is removed.

From my recollection, doctors don't standup each day to report on what they have or have not done and their individual progress, they report on purely on problematic patients that could do with expertise from a different expert, and it's not a daily progress report.

If software development followed that sort of practice, we'd have problematic issues added to a pool that gets discussed once a week. What we have is micro-management of each individual. Doctors most certainly aren't being micromanaged like that (well, not the one who I was socialising with, and not any of the others I've socialised with).

I'm not entirely sure this is more than a matter of degree. I liked most of your point but I think you devalue aspects of this mode of work discussion. It's important to discuss work and holding yourself to account in a shared endeavour is not of itself bad. I have little doubt it's also used as passive aggressive bullying sometimes.

That's the problem. Anecdotally, for many programmers I spoke with over a 20 years of career, it's not "can be used as passive aggressive bullying sometimes"; it's "almost always". :(

Likewise. Pretty much everywhere I've worked uses standup as a way of bullying people into working more hours, with a couple of unusually relaxed exceptions. It is a far cry from the origins of agile as a means of programmers defending themselves against a hostile organisation, as it was originally. Now agile is the hostile organisation.

I think at this point it should be common wisdom that anything and everything can and will be adapted to yet again introduce a power imbalance. The people who supposedly rule people -- a-hem, sorry, they manage them (heh) -- don't like it when the worker has influence of the process and especially the costs and schedules.

So they'll co-opt any newfangled trend into plain old serfdom. And they do.

As another commenter said, we should take page from the lawyers. A lot of them manage to convert bosses into paying subscribing customers.

I’ve never seen bullying in stand-up? So I’m skeptical of this “almost always”.

In fact many of the teams I’ve working are fine with people skipping standup if they have any reason to. Currently I skip like half of my teams standups.

Everywhere I've been, ever, stand-ups weren't optional.

That’s interesting. I’ve run into this a lot online. Its obvious in retrospect but often taken for granted that people can have such diverse experiences that really influence our opinions and views of the world.

The nice thing about anecdotes is that they don't say anything. For example: I have heard this for none of the programmers I've spoken with over a career of a little over half that time.

Anecdotes don't cancel each other out. They are all true at the same time.

So yes they do say a lot, maybe not what you believe but they still do say things.

> From my recollection, doctors don't standup each day to report on what they have or have not done and their individual progress, they report on purely on problematic patients that could do with expertise from a different expert, and it's not a daily progress report.

Isn't this what standups should be for developers too? It's not supposed to be a daily status report, but a discussion about blockers and an exchange of knowledge from other devs that might be able to unblock you.

At least here, doctors have a meeting every morning.

It could have actually inspired the daily standup. With the tradition of taking inspiration from surgical teams and everything...

It's interesting to consider the difference between project and event driven (ops) work.

Engineering project teams doing Scrum struggle when tasks need to be initiated and completed at a faster cadence than their sprint cycle - for instance an engineer doing development work planned monthly gets 3 calls a day asking him to reboot a server.

There are apparently better ways of managing operational work - for kanban (with or without a board), ticket systems and queues and processes and dashboards for managers to spot bottlenecks live and re-alocate workers to solve them.

I know (from TV docs) that ERs here generally have a "morning meeting" where the manager briefs people and talks through throughput statistics and demand estimates.

I don't know how to manage an ER department, but I'd understand a lot of work has been done in that area. What I could say is that it isn't project work you could plan on a monthly sprint cadence.

Burger bar workers will also generally be executing operational work according to a clear process that involves tickets and ownership of a problems (tables). I've also seen IT help desks run like this.

What I'm saying is, Scrum is one possible way of running things, but it isn't one size fits all for all kinds of work. But just people are not doing Scrum does not mean they are not working within a detailed process where they may potentially be micromanaged to the same degree.

Operational safety focused professions (not just ER) have shift change meetings, where they tell the people from the next shift what they should be wary about.

Scrum dailys are very clearly based on those, despite the fact that development work is neither operational nor shift-based. It's cargo-culting all the way down.

>I don't know how to manage an ER department, but I'd understand a lot of work has been done in that area.

Even so, the long work hours of younger doctors are infamously sub-optimal. We shouldn't submit to the assumption that something is right because everyone does it and they operate in a free market.

Are you referring to patient rounds? It seems pretty different to me - that's (usually/when well-staffed) multiple doctors (at various stages of training) working on a single bug (pun very much intended) before moving onto the next one. And it's (for all patients considered together) a significant chunk of the day: what's left of it is used to do the work that arose from the discussion (with some of that left to whoever's on overnight).

If we need to analogise it, I'd say it's more like sprint planning - discussing what's to do on each ticket (patient). Except it's longer and more detailed, and the work that's left is much more like grunt work in a way - book the scan, take the blood, chase results, etc.

> Are you referring to patient rounds?

I think it’s a reference to the Mayo Clinic team-based model [1].

For simple stuff, a single doctor executing a textbook is fine. For complex cases, doctors of different disciplines meet to discuss, create and keep track of a care plan. The analogy being most problems a programmer is tackling are assumed to be novel cases.

[1] https://catedradecronicidad.es/wp-content/uploads/2020/06/Ma...

Sure. I still think I'd make the same argument: that's a team working on one problem, not discussing/managing the one of them working on each of multiple different problems.

Otherwise we can say any team sport discusses tactics for a game and this is a daily stand-up and it works for them so why not software.

> that's a team working on one problem, not discussing/managing the one of them working on each of multiple different problems

Pursuing a common goal. But working on different problems. (Is it a blood pathology? Is the immune system misbehaving?) If a team doing a stand-up isn’t working on any sense of a common problem, they aren’t a team and aren’t working efficiently.

I mean every show I ever saw where more than one lawyer is on a case they are constantly talking about how their part is progressing, probably they don't have a standup because they talk about it so much that they don't need 10 minutes a day to let everyone know what's going on.

You do it daily when you're managing life/death-impacting operations (ER, hospitals, factories with team shifts).

Software engineering/IT RUN and SUPPORT activities MAY fit there too, but that does not even mandate a daily review. BUILD activities definitely don't.

And worse, teams mixing RUN and BUILD roles... definitely don't.