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