Hacker News Reader

Matches my experience with standups: let’s all go around the room and think of something to say and then one or two people have a long drawn out conversation with the manager.

What seems pretty universal is the amount of information i share nobody cares about and the amount of information other people share that i don’t care about are both quite high.

It serves as an opportunity to be bored and frustrated for a half hour each day and does a rather good job of interrupting my daily flow.

I think a key to a needed standup is a small group of people actually working collaboratively on something whereby the shared information is actually good to know.

I am though a fan of short meetings of any topic where you literally are standing for the meeting, it seems to change the quality.

> What seems pretty universal is the amount of information i share nobody cares about and the amount of information other people share that i don’t care about are both quite high.

Yesterday, I asked a team member if they had QA'd my project. They said, "oh I wasn't expecting to QA your project."

Yet I told them in the standup that I needed them to QA the project and I tagged them in a story. Clearly paying attention...

During standup, I've also had people say "colmvp, you can go next" despite having already spoken.

And near the end, we often don't even remember who hadn't spoken.

I feel like standups work well for small teams, but in larger teams it just feels like it becomes impersonal and more of a thing to do to make yourself appear obedient to your manager.

I am getting the feeling that there is a whole set of these cargo-cult "best practices" like standups, "1-1's", retrospectives and so on. They're not stupid ideas, but they often seem implemented in a way where... "that's the done thing", rather than something evolved organically.

I'm not a 'process guy' though so I have no idea what to replace these things with, if anything.

In my case it doesn't stop there. There's sprint planning, sprint retrospective, then a backlog grooming.

After all that there are still more architectural discussions, meetings to clarify stuff. And then we break interfaces every other day. Reason given is "way of the agile". I can't speak in general, but it seems that we couldn't design a solid software for the long run if our lives depended on it anymore.

I wonder what kind of processes industries like aviation, defense, and other high stake industries have?

Processes in aviation and defense are long, drawn out affairs but they're also the result of successfully managing projects orders of magnitude bigger than any software company could dream of. (say, a decade between drawing board and first prototype, another decade until full production)

Lots of up front planning in great detail with timelines and details dependencies. Lots of understanding how schedules slip. Some space systems go to the levels of planning for a number of bugs and if the result is off high or low, it is a matter for investigation.

Also, no daily meetings (unless culture has changed since I was inside a while back).

The most important things are an advanced method of requirements generation and change management.

It seems like almost everyone in the software industry is just making shit up as they go along which is... themed to the right way to do things but not actually doing it. Cargo cult processes.

> Also, no daily meetings (unless culture has changed since I was inside a while back).

I can confirm that the big management consulting firms are selling modified "agile" processes to the MIC and the US military itself. I suspect that means they're selling them to most large orgs with that sort of culture.

I don't know whether they're complete bullshit and don't actually mean much as far as how things actually operate—hopefully that's the case. If it's actually changing anything and not just shuffling around some names for processes, I assume it's making things worse.

Thank you for sharing! I really find these industries fascinating and hope to work in one of those someday.

> "The most important things are an advanced method of requirements generation and change management."

Makes perfect sense seeing how those wrecking havoc in far simpler software I'm working on. Thanks very much for sharing.

I have also never seen requirements or change control being done anywhere outside defense in any way near "correctly" or in a way which was useful.

It is absolutely useful when you're doing a 10 billion dollar project with dozens of contractors when your customer is say, the Army.

The way I've seen all of these things done in commercial software is like middle managers heard about requirements in an elevator while drunk and went home and decided to implement them. i.e. nobody know at all what they're doing, and they're trying to accomplish something they've heard of but never come close to experiencing done well.

I feel the same way about Agile. It came from the way a group of smart effective people worked together and decided to share... it's being implemented almost everywhere by people who are looking for a set of guidelines to follow and don't at all grok the point of any of it.

Reason given is "way of the agile".

That's just this season's excuse. How often have we seen some change that is obviously going to make things worse for a lot of individuals being justified because it's supposed to foster better team communication and so make the overall unit more productive? Open plan offices, frequent meetings, ever shorter cycles for everything, ever less up-front thought before diving in, real-time messaging on all the time, etc.

I wonder how many of today's developers, including the relatively senior ones, can even remember how productive you can be if you work out a clear brief with whoever else needs to be involved and then you are left alone to concentrate on doing the work for a while, where "a while" means at least a half-day and possibly several days.

Oh yeah? Well I have Sprint planning, Sprint planning, Sprint review, retro (maybe), emergency epic planning cause management something something, and drumroll....vulnerability management. These are the regular meetings and I'm a contractor so my schedule is really clean compared to the FTEs.

Where I work now everyone (devs, PMs, managers) have internalized that if you are not talking about something the whole team needs to know about you just briefly mention it as an "icebox" topic (we use Pivotal Tracker) which the PM tracks during the meeting. At the end of the meeting the PM lists out any icebox topics mentioned and we all briefly sort them based on the number of people that care to listen and then we go through them in that order. It is a little bit of ceremony but it works for us.

That's an interesting concept, never heard of "icebox" before. I've always used the "is this relevant to everyone" questions though. There are often short chats about topics that are extremely useful for those involved but not the whole team. If those go on longer than a minute I ask the folk involved to stop and "pick them up offline" afterwards. Saves everyone time without destroying the value.

The "icebox" term is borrowed from Pivotal Tracker (which we use for all our projects)

https://www.pivotaltracker.com/help/articles/terminology/

> The Icebox panel contains stories that have not yet been prioritized. If you want to add a story and keep it “on ice” until you’re ready to prioritize it, click the + Add Story at the top of the Icebox panel. When you’re ready to prioritize the story, drag it into the Current or Backlog panel. Icebox stories are in the unscheduled state.

"The biggest problem is that managers can easily fall into a trap where they have everyone in the same place so they can ask individuals questions that only really matter to them. Beyond about 8 people (and maybe as low as 5) this means a bunch of people are standing around while other people give updates on things they don't really care about. I've seen standups with 20 people that last 45 minutes as the manager goes around the room, basically. That's not a standup.

It's even worse if PMs and other non-eng are there. Just, stop."

A lot of managers or PMs really can't be allowed into a standup. Especially if they show only from time to time and take over the meeting.

I've been at a place with PM-driven standups. It was fine because:

1) If the team was like, "our team on this project is tiny and we all sit next to each other, so we don't need them", or "we'd rather do Slack messages for standups, on this particular project", he'd let that happen without a fuss, aside from ensuring that any communication he needed from it was still, somehow, happening. So it was still team-driven and very flexible.

2) He was very disciplined about not turning them into project status meetings, or making standup messages take the form of status updates.

[EDIT] I should add that the benefit to him was that he got to hear a lot of unvarnished truth about what was going on, which micromanagers don't get, because he was at all times, in the face he presented to the team, on "our side". That put him in a much better position for polishing up the information he had for consumption outside the team(s), which benefited us, too. He might have questions or something, and it's not that he never pushed back on anything, but he let standups be standups, and kept that stuff separate and as non-confrontational as possible.

> Especially if they show only from time to time and take over the meeting.

I do not understand the mindset that goes into thinking that somehow a person is 1. Not required for a meeting and so can only attend on occasion and 2. If present must drive the entire thing.

I guess in theory they might think they are improving things if they assume it is an unguided, unfocused disaster with out them, but in my experience it is the exact opposite: a focused, relevant, quick stand up without vs a meandering, drawn out, ritualized boilerplate, "explain to the PM stuff everyone else knows" meeting with.

PMs can be genuinely useful too. They just need to use the most important words in their toolkit: "you 2 (3,4) discuss offline/afterwards, next person". Not to be used if people are casually chatting, but to fix that problem of 2 people having a conversation while 6 others listen for no reason.

It’s called “pulling rank”. And in most situations it’s not considered an option to tell a director or VP to shut up and not disrupt the meeting.

I'm not as cynical. The "pulling rank" types definitely exist but I've worked with a lot of PMs who overshare either because they're aware the engineering team doesn't see all their work and want to "prove their value" and/or they're are genuinely excited about their work and keen to share with the engineering team. Those types always react well to gentle reminders to keep it brief.

Having a daily casual meeting where everyone brings up all of their problems and issues, and anyone in the company is welcome to listen, but not talk, is just a dumb idea. And there are never any recurring (easy) obstacles that the scrum master can resolve, and that can always wait until the next daily, the work of developing software simply doesn't work that way.

Edit: this is some bullshit inspired by rugby where you have regroup and change strategy as you learn about your opponents, what does that have to do with developing software I don't know.

If they where going to use a rugby term, I've always thought "ruck" would have been better. A ruck is quickly and dynamically formed every time progress is slowed, a scrum is a big formal process that is only necessary to restart the game after someone has screwed up.

Team rituals that trigger a productivity phase have no usefulness. Team communication has no value. Team leader having a chance to quickly gauge progress is not helpful at all.

> trigger a productivity phase

[Citation needed]. I find standups and their context switching cost me at least an hour of productivity each day.

> Team communication has no value

If you want to communicate with your teammates, just use Slack and communicate instantly, why wait for the next morning's standup? If anything, standup slows down communication.

> Team leader having a chance to quickly gauge progress

You mean like the [insert ticketing system] board? Why do we have to waste time talking about stuff that's already being tracked?

> You mean like the [insert ticketing system] board? Why do we have to waste time talking about stuff that's already being tracked?

This doesn't fully excuse it, but the more closely management is watching team-work-coordination tools like ticketing systems, and the higher the level of management that's looking at them, the more prone they are to drift from reflecting reality. That a standup is, by default, not transparent and recorded for anyone else to look at, is, in some organizations, and if they're run properly, most of their value. Granted, yes, that's a work around for a broader cultural problem and shouldn't be necessary, but the real world's a mess.

Taking time to regroup and change strategy as you learn more about your opponents (competitors in business speak) has a lot to do with developing software.

In practice, it turns out that you don't normally learn things about your competitors on a fixed regular schedule. As a result, I have yet to meet a daily (weekly, etc.) standup that hasn't devolved into "I worked on this, I will work on that." to escape the awkward silence.

Lol...there is no escaping the awkward silence on my team. We just had a meeting where every manager over our team wanted to meet with us and thank us and pat us on the back and look at us etc because we have absolutely kicked ass...not one team member said a single word the entire half hour.

No one wanted to tell them that it isn't cool, we are all burned the fuck out, the work load and pace are rediculous and most of us can't wait to fucking leave (I'm on the way out). They worshipped us, kissed our ass, were genuinely sincere, but they just don't get it. Oh well, the managers will get promoted, again.

You may have a leadership team that doesn't understand the problem domain, that is, the "opponents" in the rugby analogy. They fumble around blindly, placing their faith in the Process and the herculean effort of the dev team to eventually attain expertise through trial and error which it is leadership's responsibility to provide in the first place, or to hire appropriate experts to provide.

Alternatively, it may be the case that your leadership team is relying on the Process to insulate them from their responsibility to promote the well being of their employees, and from the loss that naturally follows when an important member of a vital team leaves the company. Rather than viewing their team as a resource to be nurtured and developed, they view you as a liability. Such companies instead develop their Process to such an extent that any member's agency and responsibility is effectively zero. Team members act like hamsters in a wheel, spinning endlessly, consuming an infinite treadmill of tickets and producing result units in 3x to 10x the amount of time it would take an empowered, impassioned developer. These inefficiencies are viewed as acceptable, even inevitable-- so deeply do they fear their employees taking meaningful ownership of their work.

Many such cases.

I disagree that the key measure should be value for ICs, or atleast engineering ICs. There are a lot of management and non-engineering IC issues that can be sorted by a quick chat. The alternative to a quick chat at standup tends to be constant Slack/Teams messages and lots of 30min meetings. ICs might not get much direct value from a daily standup but we get a lot of indirect value from moving a big chunk of those interruptions to a set time each day.

This can be badly managed, as is the case in your examples. You're right that there shouldn't be more than 8 people and it definitely shouldn't take 45 min. 15 min max and if there's more to quickly discuss the people involved should stop and continue after the meeting. The situation you're talking about with crisis mode sounds like planning rather than standup and if you're Engineering Manager is declaring crisis mode and hijacking standup each day to spend an hour planning then you've got major cultural/organisation problems. In that case standups are just a symptom not the root cause.

There's also the social aspect, which other comments have mentioned. I've always found that underrated, though I was recently reading about how some national cultures rate it a lot more than others. For me as a Brit I always feel far more comfortable communicating my colleagues when we get on socially and we understand each others sense of humor and communication styles. Taking that time to banter for a few min each morning is massively important for improving team communication. And during lockdown and WFH it's been even more essential.

My BI, Data Engineering, and Project Management team all have a shared standup. They all work on a bunch of different projects at any given time so we can't really do project specific standups. I am amazed at the dedication that the PM who runs the standup has on keeping things short, direct, and moving. About 15 folks are in on that meeting, and he's always done within 15 minutes. 17 minutes on a bad day. Any side conversations try and start up? "Let's table that".

> The biggest problem is that managers can easily fall into a trap where they have everyone in the same place so they can ask individuals questions that only really matter to them.

That can easily happen. On the other hand, where would you expect an EM to ask individual questions that matter to them ?

My experience as an EM is that this really depends on the team, including domain and maturity. For example, if you have a team of mostly junior members, well, the "micro managing" version of standup is often useful. It gives a way to see how people can communicate their issues to other team members, especially when you're new as an EM.

For more mature teams who don't have issues, I generally don't do standups, unless there is something critical and the project priorities at risk.

The weekly 1:1s or project syncs that are also happening on top of standup, schedule a new meeting with the relevant participants if that’s too late from now, Slack or email if it’s a simple Q&A, JIRA ticket if it requires some work to investigate and answer.

“The dramatic reading of the status reports,” as one former coworker put it.

We used to call it "Executive Storytime". We'd even project the status doc onto the screen AND have everyone read their part aloud to everyone in the room. Although in reality, the message was entirely for the VP and other big shots in the room, who would occasionally have questions. I imagine these are the kinds of things you think about on your deathbed, while you wonder if you spent enough time with your family throughout your life.

> The biggest problem is that managers can easily fall into a trap where they have everyone in the same place so they can ask individuals questions that only really matter to them.

In the one place I was in that did Scrum, the org had rules:

1. The "Scrum Master" is external to the team.

2. If the manager behaved this way, the Scrum Master would kick him/her out of the room - permanently if need be.

Worked well, and realistically, managers don't really want to be there.

Most companies say the word "Scrum", but break half of the Scrum rules every day. This is exactly how it should be: only developers at daily, plus the Scrum Master as an impartial moderator (mostly there to keep the daily short). But in most companies, "Scrum Master" is just a label they put on a manager, and he is doing management as usual, only with an extra excuse for daily meetings.

This is exactly my experience at multiple companies. Remote WFH has made it more tolerable.

What is an IC? (in your first sentence)

Individual Contributor