That's about right. But what I see happening, when done right, is that people are forced to talk about what's holding them up. Without it, people tend to just keep spinning their wheels instead of asking for help. With Scrum, instead of asking for help, they're forced to just state their situation, and someone will jump in and help if they can... Or at least the team lead will know about the situation within a day, instead of finding out a week later when the thing is due.

Done wrong, and it's a grueling 30-60 minute ordeal that wastes everyone's time.

It's important to keep everyone to the 3 talking points. What did you do, what's blocking you, and what will you work on.

It also keeps the team up to date with what's going on, and I know that I personally feel disconnected without that information.

Do we scrum? Nope. But we do have a meeting every morning that also doubles as a time to chat about any random things we like, and it usually runs about an hour. We take care of business stuff some time during the hour, depending on how excited someone is to talk about non-work stuff, but the work stuff can take as little as a few minutes, or as long as the hour, depending on what's happening. Joining the meeting is mandatory for programmers and project manager, but staying in the meeting isn't. That said, I don't think any programmer has ever left early unless there's some emergency. It's optional for sysadmins, and each of them has treated it differently. I think it works best when they at least pop in and say "Hi", but we leave it up to them.

An hour each day?!

It must be hell for anybody on your team having ADHD. If it's remote they probably drone the meeting out and play solitaire or something I guess.

Also, the cost...

>But what I see happening, when done right, is that people are forced to talk about what's holding them up.

I bring that up right away to the appropriate person via email or call or walk-over (when all else fails). If I had to wait until the next morning's standup, it would be less efficient.

I wish everyone did. Everyone is certainly encouraged to do that. I've found it to be pretty rare that someone brings it up within a day unless they're prompted somehow.

It is an arbitrary ritual. I never understood why everyone is so dogmatic about planning process. It’s like any other development pattern—it should be adapted to the context it’s in.

The whole point of a standup is to keep the a team coordinated and it’s manager/lead informed. Standup isn’t the only way to do this. It can happen asynchronously. It can happen at end of day. It can happen as often or as infrequently makes sense given the size, maturity, and scope of your team.

Agile and Scrum have a lot of great ideas, but there’s so much dogma and cargo curling I feel like orgs take all of the ritual with none of the insight: iterate quickly and use the delta between plans and reality to gain a sense of predictability. That’s all it really boils down to.

Engineering management is a culture. Cultures have shared mythologies and values that bind the tribe together, that tell members who they are and their place in the world. Two key commitments of this particular culture are metrics and standardization.

Otherwise rational and pragmatic leaders will either pretend not to hear you or look at you like you have three heads when you make an argument that seriously challenges one of these commitments. Very smart ones have some trite stock answers as defense mechanisms. This is because you are committing a type error. This kind of argumentation is valid with respect to rational strategies adopted instrumentally towards goals. The commitment to uniformity is deeper than that.

Scrum is the recognized best practice; we make sure that all tendrils of the organization follow a standard and that this standard is aligned with recognized best practice because that is the kind of people we are.

From my experience the problem is that Scrum guides say (or used to say, it might have changed) that in order to do Scrum, you need to do it all. So all the certified Scrum Masters learn that they have to do daily stand-ups and all the other meetings, and because they believe their job is to implement Scrum (instead of making the team more productive), they enforce it all.

Every time I worked with certified Scrum Masters I had exactly the same struggles.

You raise a good point, and I’ve seen this in other contexts.

Team wants to be better at X. Y is a tool or process that helps them get there.

At some point, the goal of X is forgotten and Y subsumes everything, sometimes to the detriment of X.

It’s like a weird correlate or inversion of the XY problem and I’ve seen it in a lot of contexts.

Good questions. The usual answer is “because it’s a good staring point for teaching the team to talk and coordinate often”. As with most scrum ceremonies, the standup should probably be adapted to match the needs of the team. It doesn’t have to be a reporting circle where you tell your PM “what did you do, what will you do, what is blocking you”.

_edit_: Adapted or removed or reinvented.

Can there ever be a prescriptive product development framework that works for all software development though? Is such a thing even possible.

  > a prescriptive product development framework that works for all software development

yes, there is, its called the "mythical man-month" (this is a trick answer)

I mean if you follow scrum by the book, then change it to 3 days a week. The whole idea is that teams can determine their process.

I agree standups are a ritual, but for me, they help me pace my day. I typically start work for standup and they are great for ad-hoc discussions and team announcements.

As an EM, Scrum notes log of what people have been working on which is helping for reviewing during performance management.

We've been trying a more "Kanban" approach vs scrum, but who knows if we're actually implementing it correctly, which is perhaps the point of all this.

There's no need to implement any sort of internal process like this "correctly". It's working correctly if it makes your team happier and more productive. It is not working correctly if it does not.

Kanban vs Scrum is not really the issue, but Kanban is certainly more honest. When a server goes down in the middle of the day and someone needs to spend 2 hours debugging the logs to get it back up, do you add a task to do that for next sprint? No, you do it right there and then. At least in Kanban the task has some chance of actually being registered in the issue tracker.

The only thing I will suggest is if you do Kanban (meaning continuous adjustments to the backlog with devs picking the higher priority tasks and doing them as needed), have a synchronization meeting from time to time, almost like a sprint retro meeting, but mainly to have the team talk about how things are going and to make it clear what everyone is working towards. The meeting doesn't need to have a specific goal or structure.

It can feel like a bit of treadmill if all you do is grab task -> do task -> mark task done all day with no larger vision, so having some synchronization moments where the whole team regroups can help with that.