| ▲ | teeray 2 days ago |
| > The main value of a standup is to have a dialogue about blockage and spark opportunities to work together. I never understood this about “blockers” as classically presented during the rites of standup. If you’re waiting up to 24 hours to voice a blocker or work with someone to resolve it, you’re waiting too long. Jump in chat with your team, tell them how you tried to unblock yourself first, then ask for help. |
|
| ▲ | crazygringo 12 hours ago | parent | next [-] |
| > If you’re waiting up to 24 hours to voice a blocker or work with someone to resolve it, you’re waiting too long. Yes, but that's part of the point. A lot of people wait too long, and a standup makes sure it doesn't wait even longer. Daily standups are a first line of defense against all sorts of bad practices. But also, standups increase visibility so things get addressed and escalated faster. Maybe you thought being blocked wasn't a huge priority, but the team lead realizes it is and ropes in someone from outside the team to help. |
|
| ▲ | mgkimsal 2 days ago | parent | prev | next [-] |
| It's odd, because I've known folks who 'wait', but most of the time, when I hear someone voice a blocker in a standup, it's notice that "this is already something I've tried unblocking by ABC, and have talked to persons XYZ, and it's still a blocker". Or sometimes, people saying "I was blocked yesterday on X for Y hours, which is putting things back a bit, but now moving forward again". So yeah, waiting until a next meeting to get announce that you're going to start working on a blocking issue is nuts, but I don't actually see that specifically all that much. |
| |
| ▲ | alistairSH 2 days ago | parent | next [-] | | This is what I see as well. "I ran into X, tried Y and Z, then asked Bob, Bob wasn't sure, anybody else have ideas?" Or "We discovered a dependency on Team Z to complete Q, Mr Bossman, can you talk to their manager, as the engineers weren't sure what to do?" And yes, both of those could be handled in Slack. But, as a manager at a medium/large company, the amount of Slack messages I get daily is MASSIVE (both direct and in channels), so a face-to-face has some value in getting the issue front-and-center (and not lost in a pile of clutter). Yes, in a perfect world, there isn't all the clutter in Slack. But, in 25 years in industry, that's rarely true. | | |
| ▲ | lucyjojo a day ago | parent [-] | | slack is a slug we need to reduce the number of slack messages. not increase the number of meetings. i want to build something like that at some point. | | |
| ▲ | dijit 11 hours ago | parent [-] | | Zulip has been extremely effective in eliminating the need to read every message for my team.
Clear public and private team channels and general “feature” channels too. Might be a few too many; but an interesting fact: in most companies there are as many channels as there are employees! |
|
| |
| ▲ | rendaw 21 hours ago | parent | prev [-] | | What's the value of saying you were blocked but now you aren't? The other case is you're saying it's a reminder. But that should be obvious from any ticketing system - the issue for what you're working on should be set to Blocked and the manager should get a status update email or be able to check it next time they're free. I think the answer is some managers prefer to have people tell them things in a call. | | |
| ▲ | mgkimsal 15 hours ago | parent | next [-] | | > What's the value of saying you were blocked but now you aren't? Going in to huge detail about it, not much, really. A quick "hey, hit an issue yesterday with ABC, Kris helped me out - thanks Kris!" does a few things. It reminds everyone we all might need to ask for help now and then. Gives a bit of public recognition to Kris who might not otherwise get it. Also lets people know Kris (and now you) know a bit more about issue ABC in case they might have a similar issue. When I hit weird snags, they're not always things I'd detail out in a ticket, especially if unrelated to the specifics of the ticket. "Add links to help documents" as a ticket doesn't benefit much from me documenting out that I hit some weird issue because the security team didn't add accounts to a new policy group, meaning my emails to the accounting team were bouncing. "Kris confirmed it was an issue for her as well, and reached out to Kevin's group to let him know, and we got things resolved yesterday". Yeah, you could add that to a ticket, but feels useful to mention that in a status meeting. Larger discussion about the process behind those changes or scheduling impact should be taken offline outside the meeting. "...should be set to Blocked..." do you do that the moment you aren't making forward progress on something? It's something I wouldn't typically do until after some amount of time understanding why I wasn't making progress, and trying to 'unblock' things first within a short period. Days of unblocking attempts without raising a flag are generally not good, but 3 minutes of 'being stuck' before pinging others is also not great imo. | |
| ▲ | addaon 10 hours ago | parent | prev | next [-] | | > What's the value of saying you were blocked but now you aren't? Pattern detection. As a coder, your job is to get past blocks and deliver features at quality and on time. As a manager, your boss's job is to take information in from their directs, synthesize a picture of what's actually going on, and work to make your life easier (and thus, you more productive) in the future. "I was blocked for four hours yesterday because <x>" isn't a big deal, for you; but seeing the commonalities in <x> across the whole team, and over a longer period of time, motivates action to understand the /underlying/ problem and improve it in the future. | |
| ▲ | swiftcoder 15 hours ago | parent | prev [-] | | > What's the value of saying you were blocked but now you aren't? It tells management why a task is behind schedule, more or less. |
|
|
|
| ▲ | frollogaston 20 hours ago | parent | prev | next [-] |
| This is hard in big teams/departments because people end up getting pinged constantly to unblock random stuff. They want to batch up and schedule things. People work on 2-3 things in parallel anyway so they can switch tasks when blocked, like Javascript. So 24hr can be the sweet spot, but as I said in another comment, I've seen the mistake of picking 7d instead! |
|
| ▲ | gwbas1c 9 hours ago | parent | prev | next [-] |
| Well, it's unprofessional to just sit and twiddle your thumbs when you're "blocked." I always find something else to work on. Chances are whoever is blocking me is also busy too. When I manage people, I always assign them multiple tasks and make it very clear that if they get stuck on one they are to move to the next. Then the next time we meet we can figure out how to unblock tasks. |
|
| ▲ | fxwin 18 hours ago | parent | prev | next [-] |
| There are people who are reluctant to ask for help with things (i know i can be), and end up wasting time trying random (non-)solutions. The standup puts these people "on the spot" and enables them to move forward within a reasonable timeframe. |
|
| ▲ | theptip 10 hours ago | parent | prev [-] |
| It’s a maturity/seniority/team cohesion thing. Junior devs might stay blocked for a week without a nudge in some pathological cases. A new team that hasn’t gelled might do the same. A seasoned team full of staff engineers might not need standup at all. |
