3 ms·

I can say that they are sometimes very useful, without them, the devs would just go into whatever useless direction or would spend days trying to solve non-prob

I can say that they are sometimes very useful, without them, the devs would just go into whatever useless direction or would spend days trying to solve non-problem. That looks like an almost total failure of both product management and team leadership. Maybe a daily standup would mitigate those failures in some superficial way but it's surely not aiming at the root causes of the unproductive team or solving the problem efficiently.

cauch 2y ago
cf. my other comments. The fact that point forecasting deviate from observations the more you go on without readjusting is not a failure of organisation, it's a fundamental and logical law of nature. It's a bit worrying that people working in this field don't even know that a constant dialogue is not the sign of a failure.
orwin 2y ago
I've seen multiple comments like this, only responding to yours, it's not personal. I disagree. If your task is simply adding a new feature or refactoring, yes, you're right . If you have to handle new data or worse, launch a new product from scratch, and only sync once every two weeks, good luck. Our dailies can last 2 minutes when nothing new is created (between 30s and 5 minutes), but also one hour, everyday, for months if a new product is on the rails. Syncing is very much needed, especially during the discovery phase. You don't want to redesign your noSQL database every 2 months.
- Silhouette 2y ago
  You seem to be reading something in my comment that was not there. If you have developers following unhelpful paths for days at a time then you don't just need a brief update in a daily standup. You need product managers who can determine and clearly articulate what needs to be built right now. You need technical leaders who can keep their teams moving towards those goals. You need developers and testers who provide feedback on what is or isn't working out promptly to those who need to know. Possibly you also need to provide significant training and/or mentoring to any or all of these people. All of this is likely to require much more frequent and detailed communication between the relevant parties than a quick team chat once per day. The point is that you need everyone to communicate at a frequency and level of detail that matches the nature of what they're currently working on. Sometimes that might mean several team members collaborating in close to real time for a week. Sometimes it might mean leaving a single person to think uninterrupted for a week so they can figure out a good solution to a difficult problem that is well defined and not going to change any time soon. So-called Agile processes that try to force real development into chunks of any fixed size and schedule process activities at any fixed frequency are going to get those scales wrong almost 100% of the time in my experience. The strange thing to me is why anyone ever expected any other outcome.
  - orwin 2y ago
    Oh ok i get it, i didn't understood your point. I totally agree with your vision.
  - cauch 2y ago
    I agree with you. But it was not what I was talking about when I was talking about useless direction and trying to solve non-problem. The situation you describe is indeed a management and leadership failure. But if you don't have management and leadership failure, you still have useless direction and trying to solve non-problem. It's just mathematical, it's just a feature of what happens when you work in a collaboration and have a group that implement the product and another group who owns it. It's not a judgement on the capacity of the devs: even the best dev will deviate. It is just because uncertainties always exist and the more you advance without realigning, the more you deviate. Let's also notice that the devs realign, but the management realign also, refining their understanding of what is possible or not and so on.

cauch 2y ago

cf. my other comments. The fact that point forecasting deviate from observations the more you go on without readjusting is not a failure of organisation, it's a fundamental and logical law of nature. It's a bit worrying that people working in this field don't even know that a constant dialogue is not the sign of a failure.

orwin 2y ago

I've seen multiple comments like this, only responding to yours, it's not personal. I disagree. If your task is simply adding a new feature or refactoring, yes, you're right . If you have to handle new data or worse, launch a new product from scratch, and only sync once every two weeks, good luck. Our dailies can last 2 minutes when nothing new is created (between 30s and 5 minutes), but also one hour, everyday, for months if a new product is on the rails. Syncing is very much needed, especially during the discovery phase. You don't want to redesign your noSQL database every 2 months.

Silhouette 2y ago
You seem to be reading something in my comment that was not there. If you have developers following unhelpful paths for days at a time then you don't just need a brief update in a daily standup. You need product managers who can determine and clearly articulate what needs to be built right now. You need technical leaders who can keep their teams moving towards those goals. You need developers and testers who provide feedback on what is or isn't working out promptly to those who need to know. Possibly you also need to provide significant training and/or mentoring to any or all of these people. All of this is likely to require much more frequent and detailed communication between the relevant parties than a quick team chat once per day. The point is that you need everyone to communicate at a frequency and level of detail that matches the nature of what they're currently working on. Sometimes that might mean several team members collaborating in close to real time for a week. Sometimes it might mean leaving a single person to think uninterrupted for a week so they can figure out a good solution to a difficult problem that is well defined and not going to change any time soon. So-called Agile processes that try to force real development into chunks of any fixed size and schedule process activities at any fixed frequency are going to get those scales wrong almost 100% of the time in my experience. The strange thing to me is why anyone ever expected any other outcome.
- orwin 2y ago
  Oh ok i get it, i didn't understood your point. I totally agree with your vision.
- cauch 2y ago
  I agree with you. But it was not what I was talking about when I was talking about useless direction and trying to solve non-problem. The situation you describe is indeed a management and leadership failure. But if you don't have management and leadership failure, you still have useless direction and trying to solve non-problem. It's just mathematical, it's just a feature of what happens when you work in a collaboration and have a group that implement the product and another group who owns it. It's not a judgement on the capacity of the devs: even the best dev will deviate. It is just because uncertainties always exist and the more you advance without realigning, the more you deviate. Let's also notice that the devs realign, but the management realign also, refining their understanding of what is possible or not and so on.