[BeetleB]

You're missing the purpose. It isn't to just sit and wait till the next day to get help. It's to highlight issues that could not be resolved in that time frame, and pointing out that help (or intervention) is necessary.

It's the equivalent of saying "Service X was down yesterday, still hasn't come up, and if nothing is done about it, we'll lose another day."

In teams without standups, these blockers could go on for several days, and no one other than that one engineer would know about it. Now everyone knows and can adjust/react accordingly.

[ipaddr]

Server is still down today.. we can forget about it until tomorrow meeting. Look it's still down.

Cancel the standup and go work on the server.

A meeting around this issue with people from other teams/external actors causing the blockage is the help you need. Not a daily status meeting. The standup rarely helps here

[BeetleB]

> Cancel the standup and go work on the server.

If someone spent 3 hours on it the previous day and couldn't get it to work, that extra 15 minutes on it are not really critical, wouldn't you agree?

> The standup rarely helps here

The standup is not intended to solve the problem, but to inform. It's to say "Hey, it's down. Tried all day to get stakeholders to work on it. It's still down because X[1]. We may not hit our commits for this sprint (or month, or quarter, or whatever)".

The goal is to keep everyone on the same page, and make a point of sync. They could have emailed this out, but in my experience, half the team isn't going to read the emails. Or they'll read it and forget it immediately because they're busy with Y. As much as people like to say it, I've found highlighting blockers in the SUM more effective.

At the other end of the spectrum, you don't want a "Oh, the server went down 5 days ago so I couldn't work on X" to be followed with "Why didn't you tell us?!" With the SUM, a lot of those surprises go away.

As an aside, in SUM-less teams, I often have seen "Why didn't you tell us?!" followed by a response pointing to the email that was sent 3 days ago telling everyone. With the SUM, if you have a good scrum master (external to your team), he will force everyone not to ignore it: "OK, this person has been blocked for 3 days due to an external team. Can anything be done about it? If not, I think it's time to inform management/stakeholders of the delay in their timelines".

As another aside: The other purpose of the SUM is to prevent someone from doing something wrong for days on end. It's common to have someone say he's blocked because of X, to be told straight away "What are you doing? You don't need X at all! We need to talk" The conversation resumes between the two after the SUM. In Scrumless teams, I've seen people work on the wrong thing for weeks because no on else knew the developer misunderstood the problem.

BTW, I'm not a fan of Scrum. When done well, it's great. But it rarely is done well. However, I've not seen Scrumless teams perform better than one with an effective Scrum. And a poorly run Scrum is often the worst of them all.

[1] X could be the team responsible isn't responding, has higher priorities, are working on it but haven't resolved it, etc.

[maxcoder4]

This sound eerie and exotic to me. In what world when server is down people wait for the next standup to announce it? Why not just create a shared channel (slack, teams, mattermost, irc, whatever the company standardized on) and use it to communicate asynchronously and resolve problems like that immediately?

[BeetleB]

> In what world when server is down people wait for the next standup to announce it?

I'm not sure why this is so strange to you. There are many possible scenarios where a server can be down, with varying levels of severity/impact to our team.

It happens all the time. I have 4 things to do. One of them involves a server (that we don't own). It goes down. I file a ticket and work on the other 3 things. It doesn't need to be resolved immediately. But if it isn't resolved in 2+ days, it may affect our timelines. People should know. If it got resolved in a few hours, I've wasted people's time by emailing them.

If it's critical and we need it resolved ASAP, sure - email/IM others in your team immediately to let them know.

> Why not just create a shared channel (slack, teams, mattermost, irc, whatever the company standardized on) and use it to communicate asynchronously and resolve problems like that immediately?

This was answered in my comment: People often ignore it. I can't count how often I've been in non-SUM teams where a developer is asked "Why didn't you tell us?" only to have him whip out one (or several) emails/IMs where he did tell it. Calling it out (repeatedly) in a SUM gives other developers less deniability, and the SM will highlight it: "This person has pointed out 3 days in a row. What's preventing it from being fixed?"

But the question for you: Are you always going to leave it to the individual developer to decide what is important to tell others? He may view it as unimportant whereas others believe it is. Making them explicitly say it as a blocker in a daily meeting ensures the disconnect doesn't last long.