> We're still attending stand-ups every day with non programmers telling us when we can and cannot refactor. It's nuts to me that a skilled profession - that not many can do - lets themselves get micro-managed like this.
This is actually quite interesting as I was just talking to a few other professionals about this in a social setting. I was the only one in software development.
I mentioned how stand-ups work briefly, and that it might not be a bad idea to adopt for (for example) an accounting department to keep things on task.
The response was both extreme and universal: How the hell do you all accept being micromanaged to such a degree? Don't any of you have any dignity?
Every single one of them (all professionals, like I said) were adamant that they would leave any position that managed them no better than a burger-flipper.
No lawyer, accountant, doctor, engineer, scientist or other professional stands up each day to report *to their peers* on their progress.
The DSU shouldn't be for non-technical people. They literally should not speak at all during this daily meeting if they are even there.
It's for Devs only to make sure they are not blocked and they are communicating what they are working on. In my last company the non-tech people weren't allowed and the DSU was only for engineering.
It is not a daily status meeting!
If it has turned into this then it should be scrapped because as you say it'll lead to people leaving as they feel they are being treated as low skill staff.
Btw I wrote this in a DSU that had non-tech people yabbering and which was basically a daily status meeting.
> If in the course of one's work one becomes blocked, would one really wait until the following day's stand-up to tell anyone about this?
There is hard block and soft block. Hard block means you have no clue how to continue and so of course you should get help right away. Soft block means you have ideas and are working on it, but - unknown to you - someone else on the team knows exactly how to solve that problem and could solve it for you in a few minutes or you can spend all weeks working out the answer. The soft block is a lot more common - engineers are smart people who can solve complex problems, but we often fail to use the help of someone else who has already solved it. Thus the standup should be able airing problems that you just need to finish typing the solution in. Sometimes someone else will say "I can help you do this faster", others it is just keep working until you get it.
Right. This sort of blockage and spotting unnecessary/undesired rabbit holes are the value of DSU. It should be a pure dev experience.
However 99% of the time what I see in Real Life is even when it's just devs talking they aren't offering up enough information for either of those to happen. Either imposter syndrome kicks in and they don't want to look stupid in front of their peers, or they're just annoyed at having a meeting. So it just becomes a status update meeting anyways
I don't know if I've heard it before, or made it up on the spot. Probably a combination: the ideas have been said before, but that exact wording is mine - maybe.
I hate DSU to be honest for this exact reason there's no way I'd way a whole day. I feel compelled to explain though that at the very least there is a definition of what you should be using it for and few companies I'm work with have ever used it for that. It's mostly used as a status meeting and becomes a micromanagers daily meeting to beat people up about poor progress.
On this same site you can read all day about developers complaining about interruptions. Now a company has big issues if someone puts a task aside to do something else until the following day where they will avoid interrupting someone?
I have come to realize as a senior engineer my job is to be interrupted. I'm equal to any better than any non-entry level engineer (and entry level will advance fast) at typing in implementations, but because I take interruptions from people I can tell them the part they are missing to solve their problem - 5 minutes of conversation with me can turn several weeks of trying to find a solution into 1 day of implementing it. It only takes a few of the above to make me a 10x engineer because I'm helping others avoid false starts in fixing their problems. (and of course when I interrupt someone else they in turn do the same for me - this is a two way street)
Somebody communicating about a blocking situation depending on your input (or output) is not an interruption.
BS "can I pick your mind", chit/chat, questions that could be Googled, and of course, micromanagement BS are interruptions.
DSUs themselves are also interruptions -- it's just that they're scheduled and not event-based.
In other words, necessary communication is not interruption. Accidental communication is interruption (to be read as the same concept as necessary and accidental complexity).
Stand ups are the bane of my life, interruption wise. Not everyone wants to work the same hours but we all have to set aside a mutually inconvenient time to distract from what we're supposed to be doing. Before the stand up, your mind's not properly on your work 'cause you know you're about to be interrupted. After the stand up, you have to get back into your work but now with less time to do it.
No of course not. In my experience standuos are best for encouraging accidental knowledge sharing - "oh I know what the issue with that is", "oh I think Dave in the other team has done that before", "I was planning on changing that" etc.
Agreed, and maybe this is more common than may impression & experience, but if that's the goal, wouldn't you prefer to do it in the afternoon? After you've spent some time on something, but perhaps still have some time left to shift approach or have a 1:1 call with someone who says they can help?
Sometimes stand-up for me means 'remind myself what I was doing'; if not that then I've certainly not got far past it, haven't had long to get much done or be stuck. I'm unlikely to say in a stand-up that I'm stuck on something, I'll have a(nother) crack at it and perhaps ask after lunch if necessary.
I wish I could get this across to my PMs, bosses and other non-technical stake-holders. Current PM is an nice guy but first of all, he absolutely loves to talk and second, he believes the "daily status meeting" format is what Scrum is all about.
To be honest I would just throw SCRUM into the trash if I could I think it's garbage but following some not quite SCRUM method which is what most companies do is actually insane.
The whole process becomes a micromanagers wet dream.
I have come to really like kanbahn methods. No two weeks sprints, no committing to work you will get done (thus needing to sandbag to ensure you meet them - management will measure this to ensure you hit your commitments 100% - though to be fair SCRUM itself says don't do this, but it happens anyway), just get take the more important story off the stack and work it, and repeat. If management changes priorities then reorder the stack and we will get to it.
It's really weird. I have resorted to reducing my workload from sprint to sprint to avoid the drama when estimates aren't met. Management is much happier now, they see "work done" and equate it with better performance. And Scrum has always been like that for me whereas Kanban types of work create a much saner work environment.
This is also my main method of improving work life. Inflating the cost of sprints lets me spend more time "working"- on chores around the house, side projects, childcare, etc.
As long as you complete what's "agreed" to (which is transparently a conflict of interest: engineers stating what can be accomplished; the ones who have to do the actual work), then everyone seems bizarrely happy.
The reduced working hours I qualify as increased salary, which prevents me from jumping ship for a better salary. I also qualify the reduced work as metal health recompense for perpetually dealing with scrum narcissists.
I used to work at a company where the standup meeting was once per week, and we would pre write everything in a shared doc. The meeting was then just silently reading, only saying something if necessary. A great place of sanity, that was.
We even have a Scrum master & certified Scrum trainer and she does not intervene which is kind of surprising considering the DSU devolved into a status meeting. You can't make it up, old industry really doesn't change.
I've been in teams with just developers, being siloed from non-programmers, with a technical manager. It still becomes a status meeting. We can tell them DSU aren't supposed to be status meeting, but it still devolves into one.
> It's for Devs only to make sure they are not blocked and they are communicating what they are working on.
If this works for you then this is good.
But I think these meetings are not for devs or something is very wrong with the setup. If they are Devs are are in the same team and working on the same project then I assume they have access to version control => no need top update on what everyone is working one. Instead teach them to do small commits and to write better commit messages.
If the meeting purpose is to communicate what is blocking someone => this again fails IMO because then someone might wait 1 day blocked? And if they don't wait that much and do an action about it what is there to communicate about in a daily meeting?
Totally agree. Not even I join the daily as I don't want to mess with the scrum master's work or invite the team to ask questions as it would create longer meetings. At our startup, the devs meet with UI/UX, QA and the scrum master, shortly discuss what's happening and move on. Max time budget of 15 minutes. The rest really is micro-management.
> No lawyer, accountant, doctor, engineer, scientist or other professional stands up each day...
I think this has a lot to do with the office culture of software being figured out at the same time as the professionalization of Management and the trend of "methodologies" to give a veneer of objectivity to the managerial class. Combined with FOMO about the fortunes being made at certain other companies, whose whims and experiments are then followed.
Whereas the other professions you mention had their office cultures defined in very different times. Once defined, these tend to be sticky.
For example the extended hazing ritual by which we mint medical doctors in the USA is completely insane and would not be tolerated by doctors in most other countries, much less by non-doctors. Or for scientists, the amount of time many of them have to spend on acquiring funding for their employers instead of doing actual science, not to mention the very broken world of peer review.
The thing that makes our situation special -- and which these people were probably reacting too -- is how transparently ridiculous, toxic, and demeaning a lot of it is. From open-plan offices to stand-ups to pair programming and on and on.
I think we put up with this stuff because we are convinced we should be thankful for our fat paychecks and fear the Barbarian Hordes waiting to take our jobs for cheap in Elbonia.[0] That both of these things are objectively false has not made much difference in the last decade, but the salaries have gone up, so...
> For example the extended hazing ritual by which we mint medical doctors in the USA is completely insane and would not be tolerated by doctors in most other countries
I married a doctor. The "hazing" is slowly going out of fashion as older doctors retire.
What they do have is a very nice licensing procedure. Yes, it's annoying, but it works a lot better when a doctor needs to get a job, because their interview process is much smoother than in the software field.
I have a wife who is a licensed nurse, and I was just blown away when I heard how the interview process goes for medical professionals. What, they trust your credentials at face value? You don't have to do procedures live in front of the interviewers? The interview is mostly _them_ trying to get you to work there?
Glad someone else is mentioning this, about 10 years ago it seemed like it was the hottest trend and that anyone (meaning any programmer) not willing to adopt it was either too lazy or had something to hide, or, most probably, both.
I'm sure there is a lot of status-related meanness everywhere but I was thinking in particular of the US practice of intentionally and radically overworking people (to a level dangerous to both them and their patients) in order to prove they can take it, which is pretty much classic hazing. Wouldn't be surprised if it's copied elsewhere but I know it's not done everywhere.
It sounds awful to me, too, but in casual conversations with medical professionals who have been through it (and in some cases while they were going through it) they very frequently defend the process. It doesn’t sound like Stockholm Syndrome or gate-keeping justifications either. They basically say that it’s the best way to see/learn the full progression of a case. Essentially it comes down to charts and records can only communicate so much and actually being there is how the real learning happens. I don’t know if I buy it, but I do know one thing — systems like this usually carry really value, or they wouldn’t be so persistent.
I'm fairly sure that's the norm almost everywhere. It's not just to prove they can take it, hospitals like to use students as free labor.
I know it happens in Western Europe.
Daily standups can be useful when its a small group of people (3 or 4) working on the same project. In such meetings participants actually have the context to make meaningful suggestions based on other's updates "oh.. have you considered this? you should try this!"
Standups with more people working on separate projects are useless*.
My most recent standup with a group of 8 who were working on many separate projects spread across mobile, front-end and server. In this meeting, even if I did share some details about what I was doing, no-one else would have the context to help me. Also, it feels disrespectful to go into detail about something highly specific to my work while 6 other faces stare blankly as I waste their time. Ive heard stories from a friend's company of a standup with 30+ people across product, engineering and management. Could you imagine going into detail about your choice between an abstract class and interface on the call?
In such standups, the only sane action is to give a quick, high level update and mute yourself and go back to work. Standups like this should be ruthlessly dived down into several smaller meetings of people actually working together.
*Interestingly though, most people on my team love the standup for another reason - human interaction. Folks simply want to tune in and say hi to their team. In my opinion though, this isn't a good enough reason to keep unproductive standups, and the meeting would be better replaced with an optional 15 minute "coffee and chat" meeting. If folks want to tune in and chit chat, great - let them do it! But no need to waste people's time with mandatory "agile" ceremony.
That's pretty much the gist of it. The ideals of "agile" (or really just Scrum for the majority of people) aren't what most developers rail against. It's how tightly the "how" is defined and acclaimed as the "one true way", despite authors repeatedly writing it isn't, and despite proof of software projects having done just fine otherwise. Which then saps the energy of many participants, making them less likely to do what they would do otherwise.
I've never heard opponents go "communication doesn't matter", yet the moment we talk about taking down these meetings, that's the first kneejerk most proponents I spoke to reach for. As if being against standups is indicative of thinking poorly of communication. Same goes for specification of goals, cooperating to keep everyone going strong, and improving to make things less of a drag. Is there so little faith in basic human intelligence and cooperation, that this one method is the only way we silly developers can be redeemed?
Now we have a bunch of people who haven't touched code in multiple years parroting what the consultants sold them and trying to talk their way out of aforementioned proof. Or they make claims like "well but it is better now!", as if their previous methodology wasn't so horrible they could've thrown a dart and very likely get a better result.
> 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.
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.
> 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.
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.
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.
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.
Have you seen how lawyers, accountants etc actually work though? It's a shit show, there's little to no project management and stress everywhere. Talk to any lawyer under 40 about their work practices and your mouth will drop. There's no autonomy, just endless pressure, confusing directions and last minute reactivity.
Trello and a standup among teams would immeasurably improve things.
(Source: I know a bunch of big firm lawyers - and ex lawyers who said "Fuck this" and quit)
> There's no autonomy, just endless pressure, confusing directions and last minute reactivity.
So, software development in a nutshell? Maybe I only have seen bad examples, but I've never seen the agile/scrum/whatever-of-the-day stop these things from happening. You have these things and at some point they add the process on top cause "we sure do need a process".
> Every single one of them (all professionals, like I said) were adamant that they would leave any position that managed them no better than a burger-flipper.
Such entitled garbage. Restaurants manage people much more tightly, and often with very abusive practices and wage theft added in.
Stand-up is nothing compared to having an underpaid alcoholic yell at you because you leaned against the wall 2/3 of the way through your second double shift in a row.
Wage theft is endemic in programming. Think of all those colleagues who have worked late on a deadline because somebody pressured them into it. They're reducing their own effective hourly rate and contributing to a long hours culture because of the daily ritual of humiliation at standup. It is very different to the restaurant analogy but wage theft and humiliation are still baked in for many of us.
> but wage theft and humiliation are still baked in for many of us
It's harder to get much sympathy from others as well if/when you're paid much higher than many other averages. Using the term 'wage theft' - normally used in discussions around minimum wage job abuses - for someone who's making $80/hr, (and may get some stock/bonus) doesn't get the same sort of reaction. The term doesn't even feel quite right, but that may be just because I've heard it so often relating to the lower end. I'd imagine it's not even about money so much for many folks as much as it is about time.
But money is time. If my employer feels strongly enough about getting something finished tonight, they’ll have to pay for it (e.g. paid overtime). This naturally limits how much overtime your company would like you to do, and puts some backpressure one those managers burning through budget like there is no tomorrow.
When you accept a salaried position, you understand that there are going to be weeks your "effective hourly" fluctuates. Some weeks I have lots of work. Some I don't. I have sympathy but that's not wage theft.
Actual wage theft is very common in food service. As in, you earn the money and someone else takes it.
Most software positions have a never ending backlog of work that can easily fill 40hrs of any week. Meaning a salary set at 40hrs/wk is pure downside to the work as your actual job expectations have a floor of 40hr weeks but sometimes 50-60hr+ weeks during crunch times.
It's essentially legalized wage theft.
Thankfully I get paid hourly, but still when I do overtime it's only paid at a x1 multiplier because the dinosaurs in office deemed 'computer workers' [1] are exempt from fair labor regulations. Likely, those in power guessed that they could safely chip away at more worker's rights because most of the voting base won't feel solidarity for highly paid salary positions and 'computer workers'.
I've worked unpaid overtime at every tech job I've had. On the flip side, I never had any wage issues in 5 years in food service, other than that the pay isn't livable.
Seriously? Do you think working at a McJob is unicorns and rainbows? Getting paid minimum wage, being on your feet all day, entitled customers constantly up your ass, a management team that literally thinks of you as a fully replaceable work unit (and you are !!)…
Yes I’ve done it. It’s not the worst job I’ve had but my current job affords me the opportunity to type this from a vacation house on the beach in Hawaii. When I told the people making my lunch last week that I was headed to Hawaii they said they always wanted to go there and hoped to do it in a couple years, like it was a once in a lifetime trip for them. And it probably is.
People need to actually pay more attention to the world around them and have some conversations to realize how well we’ve got it.
I worked a McJob (actually the McJob) from 16-20, and it was probably my main motivation in getting into the CS department at UW (it helped that I was interested in computers and seemed to have a talent for the field). Sometimes I wonder if any of my colleagues had to go through that, but many did. Surely not all of us programmers came from stable upper middle class or better backgrounds.
I did have some really good managers though, people I couldn’t believe weren’t doing better things (and some real bad ones, too, of course).
Hmm. I think there are two characteristics of software development that make it a special case.
Firstly the error rate. We make 'mistakes' (bugs) all the time, how many other professions have a dedicated QA department dedicated day in, day out entirely to catching error. Yes there's audit, but most departments only even talk to them a few times a year.
Then there's the issue that the problem domain, and the design you're trying to implement, is often very poorly understood or at least documented and specified, even by the domain experts commissioning the project. This is the whole reason we have agile.
Between squashing bugs and constantly course correcting on the direction of development, I think some of the micromanaging makes sense. There's a heck of a lot of very unstable micro that needs managing. As has been mentioned already, the nearest analogy I can come up with is medicine, particularly for critical patients with poorly understood conditions. I think a great, if completely fictional example can be seen in the frequent discussions going on between the medics in 'House'. They're constantly putting their heads together and white-boarding cases, though in reality such discussions are I'm sure much rarer than the show makes out.
The way those professions work is, generally, completely different to how programmers work.
A lawyer, accounting, or doctor will typically have their own clients that they focus on. They may ask for advice on occation but generally one of those professionals will handle many customers completely unique needs.
Lets look at an accountant for example, they will have multiple clients each of which take up a small portion of their day / month. Each has individual needs and rarely will they have any real relation or crossover in their work. It'll be even less rare that your client has anything to do with another client of your business which may be handled by another accountant. The same is the case for doctors, and lawyers as well. You have one professional serving a multitude of clients.
Programmers work differently, typically we have multiple programmers to a single client. That client may be internal or external. If your particular case needed 7 accountants, or 7 lawyers you'd be damn upset if they weren't in regular communication about the work they're doing towards your case. If they all came back with totally different suggestions that completely clashed you'd be shouting at them for not communicating together properly.
Engineers are the only ones where I think there's a stronger relation. You might only work with one engineer for a small change to your house, but on big infrastructure projects there had better be regular communication between related groups or you end up with your designs failing ragulation.
Daily standups are for the programmers in the team to get together, to de-conflict, and understand what's changing around them. If Janet is about to make a big change to the auth system and you're working on a new api endpoint you probably want to know and make sure you're not causing problems for each other.
If your daily standups are actually just 15 minutes each day where only 1-2 managers are benefiting from a statud update from everyone, then sure that's micro-management and probably wasting a hell of a lot of time. Suggest changing it to a weekly call, or having everyone email a summary each week. It's important to report status on a regular basis just as you'd be pissed if your accountant didn't let you know once they'd filed your tax returns or if your doctor had your blood test results back a week ago.
Conflating a daily standup with a daily status report though would be frustrating and probably does need challenging, but it's not easy to compare across professions like that. Their workloads are completely different to ours, and so need a different approach.
Not exactly. All professions have similar communication. Subordinates report up to their supervisors and colleagues discuss laterally with themselves, especially when in a team focused on the same project.
> "I mentioned how stand-ups ... might not be a bad idea"
That's what the other professions are taking issue with: the way software teams communicate.
Stand-ups are a terrible idea. Imposed superficial questions with rarely any nuance or relevance while eating at productive time. We need proper measured processes rather than the agile/scrum/random voodoo of the day.
It seems like all the magic processes are a "Now you have n+1 problems" problem. Everyone who invented a new process thought they were fixing what was broken in the last process.
> No lawyer, accountant, doctor, engineer, scientist or other professional stands up each day to report to their peers on their progress.
My experience when I was a tax accountant, we have a weekly status checks for around 20 people which took 1 hour, different seniors and managers breathing down your neck everyday on the progress of their projects.
As a junior, I have to manage the expectations of these managers competing for my time to prioritize their client. Sure we don't have daily standups, but I will choose daily standups over this.
As an engineer, I can verify this. I just send my boss a few bullet points in an email on Friday afternoon describing what I've been up to. I couldn't do the stand-ups that the dev groups do. I frequently need to coordinate what I'm doing with dozens of other engineers, but I never need to be micromanaged about it. Is software really that different?
> No lawyer, accountant, doctor, engineer, scientist or other professional stands up each day to report to their peers on their progress.
This just isn't true. Semiconductor process engineers and manufacturing technicians have stand-ups twice a day. I'm sure most if not all of those other professions have ~daily alignment meetings as well.
This is actually quite interesting as I was just talking to a few other professionals about this in a social setting. I was the only one in software development.
I mentioned how stand-ups work briefly, and that it might not be a bad idea to adopt for (for example) an accounting department to keep things on task.
The response was both extreme and universal: How the hell do you all accept being micromanaged to such a degree? Don't any of you have any dignity?
Every single one of them (all professionals, like I said) were adamant that they would leave any position that managed them no better than a burger-flipper.
No lawyer, accountant, doctor, engineer, scientist or other professional stands up each day to report *to their peers* on their progress.