Exactly, a lot of it just ends up being busy work that serves no actual purpose. One of the better approaches I’ve seen is to do a weekly meeting where the team identifies the features or bugs that should be addressed. Then split up into work small groups of 2-3 people to work on each task. Then at the next sync up you see where every task is at and repeat.
He said in the talk that “people are working ridiculous hours without needing to”, but I think it’s a bit naive to think that that was not the point all along. It’s like every movie ever when someone dies, follow the money and whoever just put out a high dollar life insurance policy on the victim is almost always the guilty party.
There’s likely more to it that - e.g. someone read a book somewhere and decided to increase their feelings of control, but ultimately someone wrote that book. And the managers always say like “we’ll just put this for now and adjust later if we need to”, but then make it enormously difficult to change it whenever that would be needed. They act shocked every time - shocked I tell you, shocked!:-P - whenever their estimate based on not knowing the first thing about what they are talking about ends up being wrong (how could this be!?).
I am comforted by having watched Star Trek TOS and seen engineering estimates treated the same way. So apparently this style of management predates AGILE, and even PCs:-P.
One pattern I’ve noticed working in large orgs is that management generally simply cares about self promotion. Managers want to be able to build out a portfolio of impressive looking projects they’ve supervised, and use that to climb the corporate ladder. And this often ends up turning into a sort of a pyramid scheme, where the product manager hunts for a bigger project while creating the appearance that their current project is going great. They get promoted, and somebody else gets saddled with overseeing the completion of their original project. This creates incentives to rush things, and to deliver visible features without worrying about quality or sustainability.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !programmerhumor@lemmy.ml
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
Posts must be relevant to programming, programmers, or computer science.
No NSFW content.
Jokes must be in good taste. No hate speech, bigotry, etc.
And the same with updates on tickets: meaningless if they must be made daily, or else the good stuff gets lost amidst those.
Exactly, a lot of it just ends up being busy work that serves no actual purpose. One of the better approaches I’ve seen is to do a weekly meeting where the team identifies the features or bugs that should be addressed. Then split up into work small groups of 2-3 people to work on each task. Then at the next sync up you see where every task is at and repeat.
As a side note, I really enjoyed this talk https://www.youtube.com/watch?v=QVBlnCTu9Ms
He said in the talk that “people are working ridiculous hours without needing to”, but I think it’s a bit naive to think that that was not the point all along. It’s like every movie ever when someone dies, follow the money and whoever just put out a high dollar life insurance policy on the victim is almost always the guilty party.
There’s likely more to it that - e.g. someone read a book somewhere and decided to increase their feelings of control, but ultimately someone wrote that book. And the managers always say like “we’ll just put this for now and adjust later if we need to”, but then make it enormously difficult to change it whenever that would be needed. They act shocked every time - shocked I tell you, shocked!:-P - whenever their estimate based on not knowing the first thing about what they are talking about ends up being wrong (how could this be!?).
I am comforted by having watched Star Trek TOS and seen engineering estimates treated the same way. So apparently this style of management predates AGILE, and even PCs:-P.
One pattern I’ve noticed working in large orgs is that management generally simply cares about self promotion. Managers want to be able to build out a portfolio of impressive looking projects they’ve supervised, and use that to climb the corporate ladder. And this often ends up turning into a sort of a pyramid scheme, where the product manager hunts for a bigger project while creating the appearance that their current project is going great. They get promoted, and somebody else gets saddled with overseeing the completion of their original project. This creates incentives to rush things, and to deliver visible features without worrying about quality or sustainability.
Yikes that is a scary thought… but not inaccurate:-(.
I experienced this and still get PTSD flashbacks 😢