1. Standups are a place to make people aware of problems, not the only place.

2. You don’t discuss problems at a standup, you make your team aware (if you haven’t already) and organise a separate session with only the interested people.

> You don’t discuss problems at a standup, you make your team aware (if you haven’t already)

Exactly my point. We make the team aware of problems of blockers via Slack (team channel), so there is no point in making the team aware again of such blockers in the standup.

Based on my experience sharing things in-person is much more productive. I think you're looking from a developer perspective and thinking "how can I produce as much functionality without being impeded", which is your point of view. The scrum master is likely thinking "how can we ensure the whole team has an optimal flow" and ensuring such blockers are dealt with as effectively as possible, which is more important.

Granted, most scrum masters have no idea what they're doing which likely leads to individual team members not seeing fulle value in Agile rituals, but it is there.

it absolutely makes no difference to me to have standups, yet still we participate in them...

- To see who's working on what, I just look at the board. - To seek help when I get blocked, I send a message on Slack (or whatever) at the point that I need that help, not only at 9:30 AM - To know who's blocked on what, just tune to Slack

Given the above and if you have the team discipline to make sure that tickets reflect the state of work. Why do we need standups then?

That time can be more targeted towards a meaningful discussion, but the industry seem to be blindly just doing that without giving it much deeper thought. It baffles me.

You might not.

“Individuals and interactions over processes and tools”

Doing standups for the sake of it is adherence to a process over the needs of you’re people.

Equally, a core principal of agile was always:

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”

And I think it’s always worth considering if your truth is the same for everyone on the team. This is actually something I’d bring up in a review (assuming you have those too right?). If you all agree that notifying and handling problems in Slack is enough, that checking the board is sufficient the just do that? What is stopping you?

I would also look for actually data too back it up. How often are people blocked. How do they get unblocked. How long does that take. Etc. Gives you some insight into the reality of the situation and some ammunition to get things changed if you’re team isn’t really being agile and is just doing the corporate software eng dance.

Thats sounds really quite personal to the individual / team culture and you’re likely right given you’re a part of the team and so one of the best people to know.

If standup’s aren’t solving a clear problem for you, stop doing them.

Have you spoken to your lead / manager about why you do them? How do the rest of your team feel?

I also at least have the impression (correct me if I'm wrong) that standup, and the Agile philosophy that describes them, arose before Slack and similar work-based IM systems were common.

Well, email and IRC existed at the time so I am not certain of that.

Think of the standup-time as the upper-bounds on how long a problem will block someone before everyone knows about it instead of the lower-bound on time-to-cure.

If you always know who can solve every problem for you, then you’re either not doing very interesting things or you’re burning that person out, and Management (including the engineering team leads) needs to know this.

The whole point of a standup is to create a cadence to work. But if you don’t enjoy that invented ritual on at least a certain level, you’re probably not going to benefit from it.

> Let's say we have it every day at 9:30 and I get stuck at 11:00. Does anyone really expect me to wait almost a whole day to get help, or should I just go talk to someone about it right away like a normal adult would?

The standup would be the safety net when people don't see that they're stuck, know what to do and are afraid to ask / hands down in smth they just don't see the obvious.

Uncovering this in a standup should prevent them from "wasting time" even longer.

I have rarely seen this in my experience so far; either people aren't as dumb as people believe or they know what to report to not fall into this "let me take over here, you seem to have messed up" category.

> either people aren't as dumb as people believe or they know what to report to not fall into this "let me take over here, you seem to have messed up" category.

Exactly. If you're starting to get stuck and you're afraid to ask for help, the last thing you're going to do is making that obvious in front of the whole team and/or your boss. If you didn't believe you can manage it on your own, you'd have asked for help already.

Projects often have many parts. One of them gets blocked and you work on something else for a while. Maybe you shoot off some emails and wait for replies that never come. If you get distracted, you can be in this state for a while.

Often these issues just linger until you finally talk to your manager or team about them. Having a regular opportunity to do that can speed up the process.

> So... what type of question or blocker is so unimportant that it can wait for a day to get resolved, but at the same time is so important that we need the whole team to stop working and discuss it?

A blocker or unforseen problem that you have already overcome but a) have been delayed by and b) might be of interest to the rest of the team to learn from, even if it is just for curiosity.

An example might be "this has been delayed because I discovered the underlying service is a mess and needed a good deal of changing to support the function we thought it already supported. That's now done - grab me after for details if interested - and I am now back to implementing the stuff in the story but it's been a full day of unexpected extra work."

Firstly, it's about scheduling and prioritising. If anything comes up that might be a blocker, or has been blocking you, or will in the future, you mention that as it relates to scheduling, and go solve the block whenever you want. There is zero expectation for you to wait for standup to raise any issue.

As someone new to working on a team with others devs, I’ve always wondered this too.