10:00: programming
11:00: quick meeting
12:00: #### getting back into the zone
13:00: ####
14:00: ####
this post was submitted on 23 Nov 2024
304 points (98.1% liked)
Programmer Humor
32561 readers
352 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
My most successful standups have been like:
“Okay, we’re all here. Anyone wanna take a look at anything together?”
“I need some help with XYZ. Alice, can you take a look?”
“Sure.”
“Anything else? No? Alright, let’s do it.”
Typically less than 2 minutes of whole-team time, at our desks. Really just a reserved pivot point where it’s okay to interrupt each other’s tasks to ask for some pairing time. Sometimes an unofficial second one would happen after lunch.
I find daily stand ups are completely useless because most of the useful communication can just be done by the people involved directly over email, messaging, or just talking to each other. I find it's useful to have a whole team meeting maybe like once a week just to see where everyone is at and how different parts of the project are going. There's very little reason to do that every single day.
Standups are ok if they stay fast and they are at the start or end of a day. The forced sync points are also more important in remote settings. This is especially true for new or junior employees.
I don't find whole team standups have much value aside from being checkpoints. In my experience, it's best to split up projects into tasks that can be worked on in isolation. People directly working on those tasks can organically figure out how they want to get them done and communicate with each other. The sync points can then be used to check the overall state of the project and to track critical path tasks across teams to make sure nobody is blocked.
That really only works with a mature and experienced team, which is great when you have one.
I find you need to have at least a few experienced people on any effective team otherwise it's just blind leading the blind. Pairing junior people with seniors to act as mentors tends to work well. It also lets senior developers grow. I find this works well because people tend to enjoy having ownership of their tasks.
If you're not doing your stand-up standing on one foot or wall-sits, people forget about the time.
Hmm. Can we somehow have it so that people wanting to speak need to jump rope or something? Make that speech, Dave; sweat a little.
I would react the same way if my scrum meeting was 1 hour long!
Been there, done that. Everyday would start with a 2 hour session of meetings. Daily for 30mins and then 1.5h of refinement. Day by day, for 2 years of me being there.
It, without an ounce of irony, leaves a fucking scar on you and makes you despise having meeting for the rest of your life.
About a year ago, I was working with an east coast customer while working remote on the west coast. Scrum was at 7am my time, with the customer on the call.
Probably should have been a stressful situation as they were a tough customer, our largest account in terms of ARR and PS dollars, and they loved to tell us which Data Enginners or PMs they didn’t like, who would promptly get reassigned. But honestly, having that call so early was the least stressful thing ever.
I would roll out of bed at 6:30a and make a cup of coffee, just to get my computer tuned on and ready to join the meeting by about 6:57.
Worked out great, cuz I never spent time thinking about scrum beforehand, and frankly always felt a bit energized afterwards cuz it was now time to start my work day.
Ended up working out well I guess, cuz the customer kept me on the team the entire length of the engagement.
How did you get my work schedule
Why is your scrum 1 hour long?
Because that's how it often goes. I find there are two types of scrums in practice. First is when it goes fast, and everybody just says they're working. There's no time to give any detail or context so the status update is largely meaningless. Second is when people start giving details about what they're working on, and that quickly explodes to an hour long meeting.
Participants need to find the right balance of information. I noticed it is productive when developers give just enough information for other to understand but not too much to confuse them and loose time. This is not easy to achieve..
Indeed it's not, I also find developers tend to be really bad at this task in particular.
Interesting... I've yet to see a team that didn't have regular touch bases not having the polar opposite issue, being communication happening in isolated silos and resolvable issues taking too long to bubble up. YMMV, I guess.
My experience is that doing a touch base once a week is sufficient for identifying issues, also it's not like people can't communicate directly with each other when they're stuck. If people aren't being proactive about that without having to have a daily stand up that sounds like a team culture problem.
I too had those hour long snoozefests where 99% of what's said doesn't pertain to my work, and those useless meetings that could have been a message on a Slack channel. I still feel like the sentiment is a very broad generalization based on some assumptions that may or may not apply well to every work environment.
My most recent project has direct dependencies between 5 teams just on the developer side, and multiple internal and external clients. Figuring out if we need to reach out to the stakeholders or figuring out who can help them on a particular task isn't necessarily always that straightforward, depending on scope.
Anecdotally, the devs on my team were losing a lot of their time doing all that stuff before I joined as a tech lead in August. I spend most of my non-dev time (about 50% of my time, lately) shielding the rest of the team from stakeholders, pushing back when needed, pushing back on various demands, enabling communication lines, all to protect them from context switching and let them code.
And honestly... Outside all that, agreeing with me or not, is 15 minutes of human interaction that terrible lol?
It's true that every team is different, so everybody should try to find a process that works for their specific situation. I just find that a week tends to be the amount of time you need to actually finish something non trivial, it takes a day or two to design things, a couple of days to code it, and then you need to do a bit of testing. That's the reason I see a week as a unit of time between sync points. It gives enough uninterrupted time for people do finish working on something, and then the team can sync up and figure out needs to be done next.
Obviously things do come up throughout the week, but those can usually be handled on ad hoc basis. The person who is blocked knows whom they need to reach out to. And if it really does end up being a problem that affects everybody, then you can always have a meeting to talk about it.
15 minutes of human interaction might not sound terrible, but it can be disruptive and it it takes people out of their flow. I don't think there's any value in creating disruptions for the sake of it.
because no one follows the damn guide and "scrum" is done so managers can claim the company can work "agile", because customers dont want "not agile", customers also dont want to participate in the way it would be necessary for a project thats supposed to follow the scrum guide. that also sounded good for people looking for a new job so hr wants to put that into job descriptions and now everything is scrum and agile and i still have to sneak in refactorings or have to fight to get time to work on our fricking ci pipeline or need to conspire with QA to get them time to work on test automation, because screw the notion that decisions should be done by the people doing the work.
screw "scrum", and the word "agile" should never have been taught to anyone claiming to be a "manager", we don't need managers we need people helping us getting the tools we need and trust that what we do, we do to deliver better solutions and helping us to fascilate constructive exchanges with customers.
we don't need managers we need people helping us getting the tools we need and trust that what we do
The word "manager" is extremely overloaded and barely says anything about what that person does for its team without knowing how the company operates. Where I work, the person you're describing would be someone in technical management.
I have meetings from at least 9-12 every day, which are the hours I'm the most focused. So rough
Me when I have a 30 min meeting in the middle of the day where I am the organizer and need to lead the discussion.