The process isn't to wait until the next standup. Asking for blockers is the manager's way of ensuring no-one is keeping a blocker from them. A functional team would have devs who float blockers when the arise and most of the time they would answer the question with "no blockers."
This is in contention with the usual developer gripe about being interrupted from focus. Sometimes the blocker is your teammate who doesn’t like interruptions. Or a junior has been told to or assumes they need to “figure it out” and wastes a bunch of time instead of asking.
> a junior has been told to or assumes they need to “figure it out” and wastes a bunch of time instead of asking.
Often you don't even know. More than once I've discovered someone working on a complex problem - they were making progress so didn't realize that someone else already had a solution and so they could save days of effort by asking the right person the right question.
Right. My point is there's a cohort of people here who are like "dont bother me, I only check email/slack in the morning, need extended focus time". At least some of those people are the ones who might know a thing or too, but they breed a culture of discouraging even bringing an issue up.
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.
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
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.
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?
> 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.
Often blockers can persist for several days or even weeks if they come from external factors. If your manager/team lead spots that you've reported the same blockage from infrastructure twice in a row they can chase that up for you. The idea that any given blocker could/should be resolved within the same working day is just a fantasy.
Yep, my team rarely reports blockers but when they do it's almost always some external factor. If they are reporting the same thing multiple days in a row, I can light a fire under someone's ass, otherwise I might not even know about it.
Excuse me? I didn't say anything at all about the timeline being pushed. You literally just made that up. Talk about strawmen.
Blockers that are reported on daily standups are things that can be worked around for now but will become problematic if not fixed. If something preventing my team from doing literally any part of their job they'd report it right away, of course.
I agree this is a great question. Maybe more for managers, but it let's people think "This is day 2 of that blocker, I need to step in". Sometimes junior devs will let external asks sit too long and write it off as "blocked on another team". Managers can manage this.
A better version I recently came across is “is there anything you need from anybody?”
This includes the classic “blocker” but besides that opens up for interesting conversations, encourages cooperation and isn’t overly management focused.
For the manager it helps uncover potentially hidden dependencies or team animosities.
With my workplace, this one is always kicked around at the end of standup and is usually taken as a joke. Even the boss is in it. It basically means "we're done, now back to work."
That said, about once per week someone will sincerely speak up with a blocker and get help.