Hacker News Reader

Comment by colechristensen | 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.

View on HN

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

Reply on news.ycombinator.com