Hacker News Reader

Comment by Dave3of5 | Hacker News Reader

The DSU shouldn't be for non-technical people. They literally should not speak at all during this daily meeting if they are even there.

It's for Devs only to make sure they are not blocked and they are communicating what they are working on. In my last company the non-tech people weren't allowed and the DSU was only for engineering.

It is not a daily status meeting!

If it has turned into this then it should be scrapped because as you say it'll lead to people leaving as they feel they are being treated as low skill staff.

Btw I wrote this in a DSU that had non-tech people yabbering and which was basically a daily status meeting.

View on HN

> It's for Devs only to make sure they are not blocked[..]

If in the course of one's work one becomes blocked, would one really wait until the following day's stand-up to tell anyone about this?

If so then I think both the worker and the company have bigger issues than whether the stand-up itself is a good use of time.

The mind boggles.

Agreed, and maybe this is more common than may impression & experience, but if that's the goal, wouldn't you prefer to do it in the afternoon? After you've spent some time on something, but perhaps still have some time left to shift approach or have a 1:1 call with someone who says they can help?

Sometimes stand-up for me means 'remind myself what I was doing'; if not that then I've certainly not got far past it, haven't had long to get much done or be stuck. I'm unlikely to say in a stand-up that I'm stuck on something, I'll have a(nother) crack at it and perhaps ask after lunch if necessary.

I hate DSU to be honest for this exact reason there's no way I'd way a whole day. I feel compelled to explain though that at the very least there is a definition of what you should be using it for and few companies I'm work with have ever used it for that. It's mostly used as a status meeting and becomes a micromanagers daily meeting to beat people up about poor progress.

On this same site you can read all day about developers complaining about interruptions. Now a company has big issues if someone puts a task aside to do something else until the following day where they will avoid interrupting someone?

I have come to realize as a senior engineer my job is to be interrupted. I'm equal to any better than any non-entry level engineer (and entry level will advance fast) at typing in implementations, but because I take interruptions from people I can tell them the part they are missing to solve their problem - 5 minutes of conversation with me can turn several weeks of trying to find a solution into 1 day of implementing it. It only takes a few of the above to make me a 10x engineer because I'm helping others avoid false starts in fixing their problems. (and of course when I interrupt someone else they in turn do the same for me - this is a two way street)

Somebody communicating about a blocking situation depending on your input (or output) is not an interruption.

BS "can I pick your mind", chit/chat, questions that could be Googled, and of course, micromanagement BS are interruptions.

DSUs themselves are also interruptions -- it's just that they're scheduled and not event-based.

In other words, necessary communication is not interruption. Accidental communication is interruption (to be read as the same concept as necessary and accidental complexity).

Stand ups are the bane of my life, interruption wise. Not everyone wants to work the same hours but we all have to set aside a mutually inconvenient time to distract from what we're supposed to be doing. Before the stand up, your mind's not properly on your work 'cause you know you're about to be interrupted. After the stand up, you have to get back into your work but now with less time to do it.

> If in the course of one's work one becomes blocked, would one really wait until the following day's stand-up to tell anyone about this?

There is hard block and soft block. Hard block means you have no clue how to continue and so of course you should get help right away. Soft block means you have ideas and are working on it, but - unknown to you - someone else on the team knows exactly how to solve that problem and could solve it for you in a few minutes or you can spend all weeks working out the answer. The soft block is a lot more common - engineers are smart people who can solve complex problems, but we often fail to use the help of someone else who has already solved it. Thus the standup should be able airing problems that you just need to finish typing the solution in. Sometimes someone else will say "I can help you do this faster", others it is just keep working until you get it.

Right. This sort of blockage and spotting unnecessary/undesired rabbit holes are the value of DSU. It should be a pure dev experience.

However 99% of the time what I see in Real Life is even when it's just devs talking they aren't offering up enough information for either of those to happen. Either imposter syndrome kicks in and they don't want to look stupid in front of their peers, or they're just annoyed at having a meeting. So it just becomes a status update meeting anyways

> Either imposter syndrome kicks in and they don't want to look stupid in front of their peers

This to a T. An awful lot of stuff coulda gotten crushed, quickly, if I'd just asked for help ASAP instead of siting on it and feeling dumb.

Never heard those defined before. Is there a source, or is this just a pearl of wisdom?

edit: to be clear, I think they're good definitions, just never heard a definition

I don't know if I've heard it before, or made it up on the spot. Probably a combination: the ideas have been said before, but that exact wording is mine - maybe.

No of course not. In my experience standuos are best for encouraging accidental knowledge sharing - "oh I know what the issue with that is", "oh I think Dave in the other team has done that before", "I was planning on changing that" etc.

I wish I could get this across to my PMs, bosses and other non-technical stake-holders. Current PM is an nice guy but first of all, he absolutely loves to talk and second, he believes the "daily status meeting" format is what Scrum is all about.

Send him this link:

https://www.scrum.org/resources/what-is-a-daily-scrum

From the horses mouth:

"The Daily Scrum is Not a Status Meeting"

Or maybe see about getting him certified.

But it always is.

They go around the room and everyone has to say something and it ends up being a status update.

To be honest I would just throw SCRUM into the trash if I could I think it's garbage but following some not quite SCRUM method which is what most companies do is actually insane.

The whole process becomes a micromanagers wet dream.

I have come to really like kanbahn methods. No two weeks sprints, no committing to work you will get done (thus needing to sandbag to ensure you meet them - management will measure this to ensure you hit your commitments 100% - though to be fair SCRUM itself says don't do this, but it happens anyway), just get take the more important story off the stack and work it, and repeat. If management changes priorities then reorder the stack and we will get to it.

It's really weird. I have resorted to reducing my workload from sprint to sprint to avoid the drama when estimates aren't met. Management is much happier now, they see "work done" and equate it with better performance. And Scrum has always been like that for me whereas Kanban types of work create a much saner work environment.

This is also my main method of improving work life. Inflating the cost of sprints lets me spend more time "working"- on chores around the house, side projects, childcare, etc.

As long as you complete what's "agreed" to (which is transparently a conflict of interest: engineers stating what can be accomplished; the ones who have to do the actual work), then everyone seems bizarrely happy.

The reduced working hours I qualify as increased salary, which prevents me from jumping ship for a better salary. I also qualify the reduced work as metal health recompense for perpetually dealing with scrum narcissists.

It's Putts Law https://en.m.wikipedia.org/wiki/Putt%27s_Law_and_the_Success... - but somehow management's impotence is becoming increasingly transparent.

I used to work at a company where the standup meeting was once per week, and we would pre write everything in a shared doc. The meeting was then just silently reading, only saying something if necessary. A great place of sanity, that was.

For office work that sounds great. For remote working don’t mind burning 20 min to see my coworkers faces and chat 2-3 times a week.

If it looks like a duck, walks like a duck, and quacks like a duck, then it's a duck.

A lot of `Agile` material is just doublespeak meant to sell consulting hours and training.

We even have a Scrum master & certified Scrum trainer and she does not intervene which is kind of surprising considering the DSU devolved into a status meeting. You can't make it up, old industry really doesn't change.

It is always a status meeting, even if it is advocated as not being so.

it's only a status meeting for management if management insists on being there.

kick them out.

I've been in teams with just developers, being siloed from non-programmers, with a technical manager. It still becomes a status meeting. We can tell them DSU aren't supposed to be status meeting, but it still devolves into one.

Part of the process is making sure the process works, i.e. achieves objectives. This sounds like such reviews were never done in those teams.

This attitude is something I associate with very junior developers.

"Hey you know your morning check in, this is the one true holy way that every company in the world should do it"

it's not even that it's not probably a good way to run stand-up. But the hubris is pretty extreme.

> It's for Devs only to make sure they are not blocked and they are communicating what they are working on.

If this works for you then this is good.

But I think these meetings are not for devs or something is very wrong with the setup. If they are Devs are are in the same team and working on the same project then I assume they have access to version control => no need top update on what everyone is working one. Instead teach them to do small commits and to write better commit messages.

If the meeting purpose is to communicate what is blocking someone => this again fails IMO because then someone might wait 1 day blocked? And if they don't wait that much and do an action about it what is there to communicate about in a daily meeting?

>It's for Devs only to make sure they are not blocked and they are communicating what they are working on

Devs on their own could do that, and do it better, before such BS like DSU was invented...

Totally agree. Not even I join the daily as I don't want to mess with the scrum master's work or invite the team to ask questions as it would create longer meetings. At our startup, the devs meet with UI/UX, QA and the scrum master, shortly discuss what's happening and move on. Max time budget of 15 minutes. The rest really is micro-management.

Reply on news.ycombinator.com