this post was submitted on 23 Nov 2024
320 points (97.9% liked)
Programmer Humor
32581 readers
838 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
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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.