undefined | Better HN

0 pointsBeetleB2y ago0 comments

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.

0 comments

ipaddr2y ago

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

BeetleBOP2y ago

> 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.

maxcoder42y ago

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?

1 more reply

j / k navigate · click thread line to collapse