11 ms·

But I thought the daily scrum is to give an opportunity to communicate and realign. I'm not a developer (I'm a scientist working in R&D that then needs to be i

by cauch 2y ago

But I thought the daily scrum is to give an opportunity to communicate and realign. I'm not a developer (I'm a scientist working in R&D that then needs to be implemented by developers), but I've participated to plenty of daily scrum. 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. I never had any problem to say "nothing to report on my side, working on X like yesterday". Maybe the pressure is self-inflicted by a culture that idolized unicorns and 10x coders.

aguaviva 2y ago
Without them, the devs would just go into whatever useless direction or would spend days trying to solve non-problem. Perhaps this is a sign you need better devs -- much better devs, in fact? And that Scrum, while it may appear to help by patching over this problem -- is actually masking it?
- cauch 2y ago
  I think that if a dev think that they will not do whatever without guidance, THEY need to be replaced by better devs. It's just mathematical: the possibility of interpretation of a solution is just very very big. It's not even a matter of precision of the requirements: the same way the dev cannot read the mind of the product owner, the product owner cannot read the mind of the dev and guess that when they use the term X that they always used this way, the dev will understand X' which is slightly different. Developing a solution is like some point forecasting: you forecast the next point, then use that next point as input to forecast the next point and so on. If you don't realign with observations as soon as possible, you are just deviating. It depends of the uncertainty around your points, but this uncertainty is never totally 0. Now, it's true that I'm in R&D, which may be dealing with more uncertainties. Maybe the frequency of scrum meeting should be based on that. But, pretty please, do not push to removing scrum meetings if you don't even understand that.
  - kledru 2y ago
    one reason engineers are frustrated with daily rituals is this assumption that they are aimless creatures who need constant instructions from rational beings (product managers and such)
    - aguaviva 2y ago
      Who don't actually do the work, and likely would not be able execute it no matter how hard they tried. In that vein, I've sometimes wondered if this projected insinuation (of the developers' myopic tendencies and general haplessness in this regard), far from being an untended byproduct -- is in fact the whole point of Scrum.
    - cauch 2y ago
      Well, humans are humans, and after all, it's very very clear when you scan Hacker News comments that a lot of devs are just having the assumption that managers are useless fakers that bring nothing. It would be very hypocritical to pretend that devs are the victim of managers having a bad opinion of them while at the same time having no problem to have a bad opinion of managers. Live by the sword ... My position is that it's sad and childish, in both case. Devs are not aimless creatures. But my point is that it is just physically impossible to not deviate if you don't get feedback. And importantly: your biggest deviation occurs when you don't realise there is a mismatch, so when you would NOT call a meeting. Because of that, constant re-alignment that occurs even when people of the team thinks there is no deviation are needed. It is not a judgement on the devs aimlessness, it's just a mathematical reality. It's a bit like saying: because of this disease, I need to take my pill every morning, but it is frustrating to have this assumption that I'm a aimless creatures who needs constant pill-taking, I should be able to take all the pill in one go and go on with my life.
      - aguaviva 2y ago
        A lot of devs are just having the assumption that managers are useless fakers that bring nothing. It's not an assumption. It's reasoned inference obtained through extensive observation. And it's not "managers" in general, of course. Just the ones who have no idea how to operate other than through Scrum. But my point is that it is just physically impossible to not deviate if you don't get feedback. It's not that no one wants "feedback". Rather, the perception has emerged that the rituals of Scrum are a pretty lousy (and basically counterproductive) way of delivering that feedback. because of this disease, I need to take my pill every morning, Except it turns out the "pill" in this case is a quack cure, basically. That's why people are resistant to taking it.
- marcosdumay 2y ago
  It's a sign he needs better management.
Silhouette 2y ago
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.
zokier 2y ago
The point of dailies should not be to make sure that devs work on the right stuff, that should be part of managing backlog and sprint plannings. Instead the point of dailies should be to avoid devs hitting head on wall and clear out any blockers for progress. Having reserved timeslot for syncing also should reduce random pings during the day which should allow people then to focus more on their tasks instead of getting interrupted all the time.
- cauch 2y ago
  Agreed, but in practice, I think needing to wait for sprint planning is very time-wasting and in practice not efficient. If a dev has worked 3 days in the wrong direction, they will naturally try to salvage some of the bad things, or even try to pretend that their solution is "the only way". It can be negotiated, with more or less success, but the negotiation itself is a waste of time if it could have been caught earlier. 100% agree with planning the meeting to avoid flow interruption. It's strange to see so many people here saying that you can just "ask whenever" when the argument about avoiding interruption is brought so often.
beryilma 2y ago
Why is it that the developers would go into useless directions and solve non-problems? Perhaps they were not given good directions and a well-defined problem in the first place? It is this attitude toward developers that made stupid shit like Scrum possible. Processes will not solve communication problems if there is no mutual trust to start with.
- cauch 2y ago
  Cf. my other comments: the developers would go into useless directions and solve non-problems the same way that if you predict tomorrow weather, and then predict after-tomorrow weather, and then predict after-after-tomorrow weather, ... you slowly deviate from the reality unless you readjust with the observations.
chucksmash 2y ago
> I never had any problem to say "nothing to report on my side, working on X like yesterday". If daily scrum is essentially a status meeting by-any-other-name and nobody is much bothered by what your status is....then maybe you don't need to be giving a status to begin with? Seems like functionally you are more of an observer than a participant and you just throw in a status as a "when in Rome" token. For the managers in the room, "uhhhh, lots of meetings yesterday" is a fine status to give day after day. Watch what happens to a programmer who gives an honest status of "uhhhh lots of meetings yesterday, not a lot of progress on X" though. They're inviting attention. There's an added onus on devs that they need to come up with a way to describe what they did the day before (no matter how small) such that non-dev listeners can hear some epsilon of progress was made. Because if it doesn't sound like progress, it sounds like no-progress. And then people who don't understand how any of it works want to start trying to understand. And now you've got two problems.
- cauch 2y ago
  Obviously, I don't say "nothing to report" in every meeting. The reality is that sometimes you need to readjust, and sometimes not, and it is impossible to know before hand and confronting your forecast with the observations. And, from my experience, devs over-estimate greatly how much non-devs care about them and their "number of line of code written" pissing contest
  - chucksmash 2y ago
    > And, from my experience, devs over-estimate greatly how much non-devs care about them and their "number of line of code written" pissing contest. Your experience as a non-dev who doesn't manage devs? Noted. Unfortunately, the people signing our paychecks do care, and so devs have incentives to continue doing the same strange dance every morning.
    - cauch 2y ago
      > Unfortunately, the people signing our paychecks do care From your experience of a dev, not a non-dev who manage devs? Noted. My point is that I have observed, with my own eyes, devs BELIEVING they need to do the dance in front of a given manager while I've observed the same manager giving bigger paychecks to another dev that did not do the dance. They may be several reasons for that, including sometimes the manager's fault, but also sometimes the dev's fault. For example, in the case I think of, the dev who was "doing the dance" was also not getting promoted or being trusted by their promoter. The reason was that they were often unreliable. But the dev in question said few time that if they were not promoted it was because they did not "do the dance" enough. When you are a bad dev, it's easy to blame the lack of promotion on "I'm in fact totally good, it's just that my manager is an idiot who cannot recognize good when they see it". (PS: I'm not saying you are not good or that you are believing you need to do the dance while you don't need to. But if you are not aware that this happens a lot, then you are indeed missing a big part of the full picture and your opinion on the situation is not at all trustworthy)

by cauch 2y ago

aguaviva 2y ago

Without them, the devs would just go into whatever useless direction or would spend days trying to solve non-problem. Perhaps this is a sign you need better devs -- much better devs, in fact? And that Scrum, while it may appear to help by patching over this problem -- is actually masking it?

cauch 2y ago
I think that if a dev think that they will not do whatever without guidance, THEY need to be replaced by better devs. It's just mathematical: the possibility of interpretation of a solution is just very very big. It's not even a matter of precision of the requirements: the same way the dev cannot read the mind of the product owner, the product owner cannot read the mind of the dev and guess that when they use the term X that they always used this way, the dev will understand X' which is slightly different. Developing a solution is like some point forecasting: you forecast the next point, then use that next point as input to forecast the next point and so on. If you don't realign with observations as soon as possible, you are just deviating. It depends of the uncertainty around your points, but this uncertainty is never totally 0. Now, it's true that I'm in R&D, which may be dealing with more uncertainties. Maybe the frequency of scrum meeting should be based on that. But, pretty please, do not push to removing scrum meetings if you don't even understand that.
- kledru 2y ago
  one reason engineers are frustrated with daily rituals is this assumption that they are aimless creatures who need constant instructions from rational beings (product managers and such)
  - aguaviva 2y ago
    Who don't actually do the work, and likely would not be able execute it no matter how hard they tried. In that vein, I've sometimes wondered if this projected insinuation (of the developers' myopic tendencies and general haplessness in this regard), far from being an untended byproduct -- is in fact the whole point of Scrum.
  - cauch 2y ago
    Well, humans are humans, and after all, it's very very clear when you scan Hacker News comments that a lot of devs are just having the assumption that managers are useless fakers that bring nothing. It would be very hypocritical to pretend that devs are the victim of managers having a bad opinion of them while at the same time having no problem to have a bad opinion of managers. Live by the sword ... My position is that it's sad and childish, in both case. Devs are not aimless creatures. But my point is that it is just physically impossible to not deviate if you don't get feedback. And importantly: your biggest deviation occurs when you don't realise there is a mismatch, so when you would NOT call a meeting. Because of that, constant re-alignment that occurs even when people of the team thinks there is no deviation are needed. It is not a judgement on the devs aimlessness, it's just a mathematical reality. It's a bit like saying: because of this disease, I need to take my pill every morning, but it is frustrating to have this assumption that I'm a aimless creatures who needs constant pill-taking, I should be able to take all the pill in one go and go on with my life.
    - aguaviva 2y ago
      A lot of devs are just having the assumption that managers are useless fakers that bring nothing. It's not an assumption. It's reasoned inference obtained through extensive observation. And it's not "managers" in general, of course. Just the ones who have no idea how to operate other than through Scrum. But my point is that it is just physically impossible to not deviate if you don't get feedback. It's not that no one wants "feedback". Rather, the perception has emerged that the rituals of Scrum are a pretty lousy (and basically counterproductive) way of delivering that feedback. because of this disease, I need to take my pill every morning, Except it turns out the "pill" in this case is a quack cure, basically. That's why people are resistant to taking it.
marcosdumay 2y ago
It's a sign he needs better management.

Silhouette 2y ago

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.

zokier 2y ago

The point of dailies should not be to make sure that devs work on the right stuff, that should be part of managing backlog and sprint plannings. Instead the point of dailies should be to avoid devs hitting head on wall and clear out any blockers for progress. Having reserved timeslot for syncing also should reduce random pings during the day which should allow people then to focus more on their tasks instead of getting interrupted all the time.

cauch 2y ago
Agreed, but in practice, I think needing to wait for sprint planning is very time-wasting and in practice not efficient. If a dev has worked 3 days in the wrong direction, they will naturally try to salvage some of the bad things, or even try to pretend that their solution is "the only way". It can be negotiated, with more or less success, but the negotiation itself is a waste of time if it could have been caught earlier. 100% agree with planning the meeting to avoid flow interruption. It's strange to see so many people here saying that you can just "ask whenever" when the argument about avoiding interruption is brought so often.

beryilma 2y ago

Why is it that the developers would go into useless directions and solve non-problems? Perhaps they were not given good directions and a well-defined problem in the first place? It is this attitude toward developers that made stupid shit like Scrum possible. Processes will not solve communication problems if there is no mutual trust to start with.

cauch 2y ago
Cf. my other comments: the developers would go into useless directions and solve non-problems the same way that if you predict tomorrow weather, and then predict after-tomorrow weather, and then predict after-after-tomorrow weather, ... you slowly deviate from the reality unless you readjust with the observations.

chucksmash 2y ago

> I never had any problem to say "nothing to report on my side, working on X like yesterday". If daily scrum is essentially a status meeting by-any-other-name and nobody is much bothered by what your status is....then maybe you don't need to be giving a status to begin with? Seems like functionally you are more of an observer than a participant and you just throw in a status as a "when in Rome" token. For the managers in the room, "uhhhh, lots of meetings yesterday" is a fine status to give day after day. Watch what happens to a programmer who gives an honest status of "uhhhh lots of meetings yesterday, not a lot of progress on X" though. They're inviting attention. There's an added onus on devs that they need to come up with a way to describe what they did the day before (no matter how small) such that non-dev listeners can hear some epsilon of progress was made. Because if it doesn't sound like progress, it sounds like no-progress. And then people who don't understand how any of it works want to start trying to understand. And now you've got two problems.

cauch 2y ago
Obviously, I don't say "nothing to report" in every meeting. The reality is that sometimes you need to readjust, and sometimes not, and it is impossible to know before hand and confronting your forecast with the observations. And, from my experience, devs over-estimate greatly how much non-devs care about them and their "number of line of code written" pissing contest
- chucksmash 2y ago
  > And, from my experience, devs over-estimate greatly how much non-devs care about them and their "number of line of code written" pissing contest. Your experience as a non-dev who doesn't manage devs? Noted. Unfortunately, the people signing our paychecks do care, and so devs have incentives to continue doing the same strange dance every morning.
  - cauch 2y ago
    > Unfortunately, the people signing our paychecks do care From your experience of a dev, not a non-dev who manage devs? Noted. My point is that I have observed, with my own eyes, devs BELIEVING they need to do the dance in front of a given manager while I've observed the same manager giving bigger paychecks to another dev that did not do the dance. They may be several reasons for that, including sometimes the manager's fault, but also sometimes the dev's fault. For example, in the case I think of, the dev who was "doing the dance" was also not getting promoted or being trusted by their promoter. The reason was that they were often unreliable. But the dev in question said few time that if they were not promoted it was because they did not "do the dance" enough. When you are a bad dev, it's easy to blame the lack of promotion on "I'm in fact totally good, it's just that my manager is an idiot who cannot recognize good when they see it". (PS: I'm not saying you are not good or that you are believing you need to do the dance while you don't need to. But if you are not aware that this happens a lot, then you are indeed missing a big part of the full picture and your opinion on the situation is not at all trustworthy)