What seems pretty universal is the amount of information i share nobody cares about and the amount of information other people share that i don’t care about are both quite high.

It serves as an opportunity to be bored and frustrated for a half hour each day and does a rather good job of interrupting my daily flow.

I think a key to a needed standup is a small group of people actually working collaboratively on something whereby the shared information is actually good to know.

I am though a fan of short meetings of any topic where you literally are standing for the meeting, it seems to change the quality.

Yesterday, I asked a team member if they had QA'd my project. They said, "oh I wasn't expecting to QA your project."

Yet I told them in the standup that I needed them to QA the project and I tagged them in a story. Clearly paying attention...

During standup, I've also had people say "colmvp, you can go next" despite having already spoken.

And near the end, we often don't even remember who hadn't spoken.

I feel like standups work well for small teams, but in larger teams it just feels like it becomes impersonal and more of a thing to do to make yourself appear obedient to your manager.

After all that there are still more architectural discussions, meetings to clarify stuff. And then we break interfaces every other day. Reason given is "way of the agile". I can't speak in general, but it seems that we couldn't design a solid software for the long run if our lives depended on it anymore.

I wonder what kind of processes industries like aviation, defense, and other high stake industries have?

Lots of up front planning in great detail with timelines and details dependencies. Lots of understanding how schedules slip. Some space systems go to the levels of planning for a number of bugs and if the result is off high or low, it is a matter for investigation.

Also, no daily meetings (unless culture has changed since I was inside a while back).

The most important things are an advanced method of requirements generation and change management.

It seems like almost everyone in the software industry is just making shit up as they go along which is... themed to the right way to do things but not actually doing it. Cargo cult processes.

I can confirm that the big management consulting firms are selling modified "agile" processes to the MIC and the US military itself. I suspect that means they're selling them to most large orgs with that sort of culture.

I don't know whether they're complete bullshit and don't actually mean much as far as how things actually operate—hopefully that's the case. If it's actually changing anything and not just shuffling around some names for processes, I assume it's making things worse.

> "The most important things are an advanced method of requirements generation and change management."

Makes perfect sense seeing how those wrecking havoc in far simpler software I'm working on. Thanks very much for sharing.

It is absolutely useful when you're doing a 10 billion dollar project with dozens of contractors when your customer is say, the Army.

The way I've seen all of these things done in commercial software is like middle managers heard about requirements in an elevator while drunk and went home and decided to implement them. i.e. nobody know at all what they're doing, and they're trying to accomplish something they've heard of but never come close to experiencing done well.

I feel the same way about Agile. It came from the way a group of smart effective people worked together and decided to share... it's being implemented almost everywhere by people who are looking for a set of guidelines to follow and don't at all grok the point of any of it.

That's just this season's excuse. How often have we seen some change that is obviously going to make things worse for a lot of individuals being justified because it's supposed to foster better team communication and so make the overall unit more productive? Open plan offices, frequent meetings, ever shorter cycles for everything, ever less up-front thought before diving in, real-time messaging on all the time, etc.

I wonder how many of today's developers, including the relatively senior ones, can even remember how productive you can be if you work out a clear brief with whoever else needs to be involved and then you are left alone to concentrate on doing the work for a while, where "a while" means at least a half-day and possibly several days.

I'm not a 'process guy' though so I have no idea what to replace these things with, if anything.

https://www.pivotaltracker.com/help/articles/terminology/

> The Icebox panel contains stories that have not yet been prioritized. If you want to add a story and keep it “on ice” until you’re ready to prioritize it, click the + Add Story at the top of the Icebox panel. When you’re ready to prioritize the story, drag it into the Current or Backlog panel. Icebox stories are in the unscheduled state.

It's even worse if PMs and other non-eng are there. Just, stop."

A lot of managers or PMs really can't be allowed into a standup. Especially if they show only from time to time and take over the meeting.

1) If the team was like, "our team on this project is tiny and we all sit next to each other, so we don't need them", or "we'd rather do Slack messages for standups, on this particular project", he'd let that happen without a fuss, aside from ensuring that any communication he needed from it was still, somehow, happening. So it was still team-driven and very flexible.

2) He was very disciplined about not turning them into project status meetings, or making standup messages take the form of status updates.

[EDIT] I should add that the benefit to him was that he got to hear a lot of unvarnished truth about what was going on, which micromanagers don't get, because he was at all times, in the face he presented to the team, on "our side". That put him in a much better position for polishing up the information he had for consumption outside the team(s), which benefited us, too. He might have questions or something, and it's not that he never pushed back on anything, but he let standups be standups, and kept that stuff separate and as non-confrontational as possible.

I do not understand the mindset that goes into thinking that somehow a person is 1. Not required for a meeting and so can only attend on occasion and 2. If present must drive the entire thing.

I guess in theory they might think they are improving things if they assume it is an unguided, unfocused disaster with out them, but in my experience it is the exact opposite: a focused, relevant, quick stand up without vs a meandering, drawn out, ritualized boilerplate, "explain to the PM stuff everyone else knows" meeting with.

PMs can be genuinely useful too. They just need to use the most important words in their toolkit: "you 2 (3,4) discuss offline/afterwards, next person". Not to be used if people are casually chatting, but to fix that problem of 2 people having a conversation while 6 others listen for no reason.

Edit: this is some bullshit inspired by rugby where you have regroup and change strategy as you learn about your opponents, what does that have to do with developing software I don't know.

In practice, it turns out that you don't normally learn things about your competitors on a fixed regular schedule. As a result, I have yet to meet a daily (weekly, etc.) standup that hasn't devolved into "I worked on this, I will work on that." to escape the awkward silence.

No one wanted to tell them that it isn't cool, we are all burned the fuck out, the work load and pace are rediculous and most of us can't wait to fucking leave (I'm on the way out). They worshipped us, kissed our ass, were genuinely sincere, but they just don't get it. Oh well, the managers will get promoted, again.

Alternatively, it may be the case that your leadership team is relying on the Process to insulate them from their responsibility to promote the well being of their employees, and from the loss that naturally follows when an important member of a vital team leaves the company. Rather than viewing their team as a resource to be nurtured and developed, they view you as a liability. Such companies instead develop their Process to such an extent that any member's agency and responsibility is effectively zero. Team members act like hamsters in a wheel, spinning endlessly, consuming an infinite treadmill of tickets and producing result units in 3x to 10x the amount of time it would take an empowered, impassioned developer. These inefficiencies are viewed as acceptable, even inevitable-- so deeply do they fear their employees taking meaningful ownership of their work.

Many such cases.

[Citation needed]. I find standups and their context switching cost me at least an hour of productivity each day.

> Team communication has no value

If you want to communicate with your teammates, just use Slack and communicate instantly, why wait for the next morning's standup? If anything, standup slows down communication.

> Team leader having a chance to quickly gauge progress

You mean like the [insert ticketing system] board? Why do we have to waste time talking about stuff that's already being tracked?

This doesn't fully excuse it, but the more closely management is watching team-work-coordination tools like ticketing systems, and the higher the level of management that's looking at them, the more prone they are to drift from reflecting reality. That a standup is, by default, not transparent and recorded for anyone else to look at, is, in some organizations, and if they're run properly, most of their value. Granted, yes, that's a work around for a broader cultural problem and shouldn't be necessary, but the real world's a mess.

This can be badly managed, as is the case in your examples. You're right that there shouldn't be more than 8 people and it definitely shouldn't take 45 min. 15 min max and if there's more to quickly discuss the people involved should stop and continue after the meeting. The situation you're talking about with crisis mode sounds like planning rather than standup and if you're Engineering Manager is declaring crisis mode and hijacking standup each day to spend an hour planning then you've got major cultural/organisation problems. In that case standups are just a symptom not the root cause.

There's also the social aspect, which other comments have mentioned. I've always found that underrated, though I was recently reading about how some national cultures rate it a lot more than others. For me as a Brit I always feel far more comfortable communicating my colleagues when we get on socially and we understand each others sense of humor and communication styles. Taking that time to banter for a few min each morning is massively important for improving team communication. And during lockdown and WFH it's been even more essential.

That can easily happen. On the other hand, where would you expect an EM to ask individual questions that matter to them ?

My experience as an EM is that this really depends on the team, including domain and maturity. For example, if you have a team of mostly junior members, well, the "micro managing" version of standup is often useful. It gives a way to see how people can communicate their issues to other team members, especially when you're new as an EM.

For more mature teams who don't have issues, I generally don't do standups, unless there is something critical and the project priorities at risk.

In the one place I was in that did Scrum, the org had rules:

1. The "Scrum Master" is external to the team.

2. If the manager behaved this way, the Scrum Master would kick him/her out of the room - permanently if need be.

Worked well, and realistically, managers don't really want to be there.