"Now we all know that story points represent complexity rather than a specific amount of time, but let's just say that hypothetically each story point is a day."
"So you want to know how many days it's going to take?"
"Well no, but actually yes."
this post was submitted on 16 Jan 2024
1 points (66.7% liked)
Programmer Humor
32476 readers
611 users here now
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.
founded 5 years ago
MODERATORS
People who tell you to do scrum correctly are themselves not doing scrum correctly.
the no true scrum master problem :)
All deadlines are made up, whether scrum is involved or not.
Sometimes I feel like sprints put unnecessary pressure on the team. It's always a rush to finish things in two weeks. Scrums, which are supposed to be 15 min at always at least twice that long. And most projects I've been on have been bogged down by so many other meetings that the team never finished their work within the sprint deadline.
I find scrum tends to focus people on doing small tasks without considering the big picture. A lot of the time you start doing a task, and then you realize there are other aspects of the system that may need to be changed to accommodate the functionality. With scrum the tendency is to just to make a kludge so you can mark the feature as complete without thinking about the broader implications.
And what I find happens with standups is that updates are either meaningless because you don't have the context of the work other people are doing, or people start going into details and the meeting drags on for an hour.
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.