Hacker News Reader

Comment by cauch | Hacker News Reader

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.

View on HN

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.

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.

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?

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.

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)

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.

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.

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.

What a very balanced opinion that will not at all reenforce my idea that some devs are just idiots blaming managers for everything.

Managers that micromanage are idiots. If they would have been a dev, they would have been a dev that explains that all managers are obviously useless.

> Except it turns out the "pill" in this case is a quack cure, basically. That's why people are resistant to taking it.

The analogy flew very high above your head. I was responding to the logic "if it's daily, it's the proof it's because they believe we are aimless creatures that need to be managed". I just give an example where someone is asked to do something daily, and yet it is clearly not because of that.

A dev that explains that all managers are obviously useless.

You keep coming back to this caricature. And yet, I've never met anyone with this opinion.

I just give an example where someone is asked to do something daily, and yet it is clearly not because of that.

Right, you said they were being asked to (in reality: made to, not "asked to") do that because they effectively had a "disease".

When management takes that attitude about its rare and precious talent, well, all bets are off.

It's a sign he needs better management.

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.

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.

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.

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.

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.

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.

Oh ok i get it, i didn't understood your point. I totally agree with your vision.

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.

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

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

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

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

> From your experience of a dev, not a non-dev who manage devs? Noted.

Would you take my experience as a dev who went into management, then returned to IC work?

I can't claim to speak for every company. I've only worked at 4 over the past 15 years, but I can only think of one where I'd raise eyebrows in standup if I reported not making progress on my ticket due to meetings, and that's because I'd have to explain how I managed to find that many meetings to attend (they were big on not hitting devs with too many meetings, and were actually good at it). For the rest it'd get an understanding grimace and an expression of hope that today's better.

Not sure of your point. When I read the rest of your comment, it seems like you agree with me: saying you did not progress as a dev is not such a big deal for non-devs (3 in 4), and when it was, it was because the reasons are surprising (having too much meetings when the company tries hard to reduce the meeting invites to ask more questions to understand why there is disconnect between the objective and the reality).

Reply on news.ycombinator.com