Managers want numbers and they're too pussy to make them up themselves so they make devs do it so they can point fingers when things are taking too long.
It's so funny to me that the entire point of these frameworks is to minimize managerial positions and managerial inefficiency but you see it applied by corporations with bloated administrative structures which just makes everything work worse than the traditional workflow
>Have Scrum Master >Dude shows up for 15 minutes for the daily >Shows up for retro every three weeks where we do literal kindergarten level shit >Asks moronic non technical questions because he can't give input on anything else >Literally doesn't do anything else >Is paid substantially more than any dev
It's literally a scam.
Yeah but you don't need a "scrum master" for that.
2 weeks ago
Anonymous
In my project the project manager is also the """scrum master""", so it works out.
2 weeks ago
Anonymous
Yeah at my workplace those are two separate
roles and people, we have full time """scrum masters""".
I have literally no idea what the frick they do all day, I'm pretty sure ours couldn't even tell you what the project were working on even does.
2 weeks ago
Anonymous
erm... its not scrum master anymore chuddy, its "agile lead" now
Scrum has the opposite effect in corpo land because you can actually get team approved slack time. My team always overestimated story points so I always had plenty of time to finish my tasks and no moronic exec asking every 5 seconds where the project is.
agile is the true way to build software
not JIRA agile, not agile + scrum, just agile. >Individuals and interactions over processes and tools >Working software over comprehensive documentation >Customer collaboration over contract negotiation >Responding to change over following a plan
How stupid do you have to be to not understand:
1 - easy as frick
3 - maybe a day
5 - maybe a week
8 - more than a week
13+ - should be broken down to smaller tasks
Where I work it's:
1-3: 1 or 2 hours of dev and simple/no testing
5: still kinda easy to develop and test
8: probably a day o dev, some elaborate testing and some bug fixes
13: a little harder
21: somewhat harder
34: dios mio
55: sto-
89: aaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Your system is a little more complicated but it's relative anyways, as long as people try to put their points relatively right the velocity charts will be correct. The whole point is to have some transparency and have the project manager have some insight on who is struggling or having roadblocks. At least in my experience with a good project manager it was how they beat the morons who put in sprint bombs away.
I detest all those "tools". Especially the problem solving tools. If the problem can be solved with a problem solving tool then it is trivial and you could have just solved it by thinking. If you can't solve the problem easily then problem solving tools will not help you.
I worked at a company a while back that started scrum a few months before I left. Our sprint retro and point planning took 2+ hours every other week and planning poker regularly ran over due to people arguing about points.
What's wrong with waterfall? I know it gets a bad rap, but I feel like treating software engineering like physical engineering might lead to projects with actual standards applied.
Because 90% of the time your initial project is shit and not what customers want. So you benefit a lot from doing an MVP and rapidly innovating based on usage patterns. Waterfall projects tend to be monolith multi-year projects and you can't develop like that today with the pace of competition.
Maybe I've just worked with shit companies, but that rapid innovation seems to lead to fragile solutions with technical debt held together by bubblegum and paperclips.
I've only worked in "agile" teams thoughbeit, so this might just be a case of the grass looking greener.
How do they get away with it in non-software engineering? Is it just a matter of SWE's being pushovers for clients, while physical engineers will tell them to frick off or better define their requirements?
Because with non-software engineering you're talking about a lot people of many disciplines involved in a project which means you have to line up everything years in advance, you don't build a skyscraper willy nilly and there are many examples of companies going bankrupt because their project failing halfway through so it's not like waterfall saves them, it's just impractical if not impossible to do agile with a real-world engineering project. Of course in highly regulated software you have to do waterfall because you need to plan for and develop for legal requirements up front.
Maybe I've just worked with shit companies, but that rapid innovation seems to lead to fragile solutions with technical debt held together by bubblegum and paperclips.
I've only worked in "agile" teams thoughbeit, so this might just be a case of the grass looking greener.
Your goal is to make a product ASAP that makes money, once you're making money you can properly redesign your software. The problem with waterfall if you don't know which part of your software is going to be what customers resonate with, you can waste 80% of your time on a set of features you throw away. I've personally seen this happen multiple times, often the thing you think will be making they money is the thing no one uses. Personally I think it's better to think of your software in one month feature chunks with some long term goals you're aiming for.
>How do they get away with it in non-software engineering?
I am luckily not involved with the part of my company that adopted agile shit but it is probably like our PLM software. Providers of the system sell it as looking really nice and being really great to the people up top. People up top eat up the presentation and buy the system. And then people who use the system suffer because system is bought and you have to use it.
humiliation ritual
humiliation ritual
humiliation ritual
Managers want numbers and they're too pussy to make them up themselves so they make devs do it so they can point fingers when things are taking too long.
Why does OP hate his job?
I love my job, I just don't get them random numbers.
Classrooms and schools are adopting agile concepts it's hilarious and sad.
Some one post the polyamorous couple that adopted agile to manage their relationship
This?
https://www.businessinsider.com/polyamorous-couple-used-agile-scrum-to-improve-communication-jealousy-2024-4
wtf source?
Humiriashon richruar
Also it's okay but the vocabulary is gay as frick like user stories and sprints. Some roastie had to make that shit up.
It's so funny to me that the entire point of these frameworks is to minimize managerial positions and managerial inefficiency but you see it applied by corporations with bloated administrative structures which just makes everything work worse than the traditional workflow
>Have Scrum Master
>Dude shows up for 15 minutes for the daily
>Shows up for retro every three weeks where we do literal kindergarten level shit
>Asks moronic non technical questions because he can't give input on anything else
>Literally doesn't do anything else
>Is paid substantially more than any dev
It's literally a scam.
up for retro every three weeks where we do literal kindergarten level shit
tbf retros are good when you have a lot to b***h about.
Yeah but you don't need a "scrum master" for that.
In my project the project manager is also the """scrum master""", so it works out.
Yeah at my workplace those are two separate
roles and people, we have full time """scrum masters""".
I have literally no idea what the frick they do all day, I'm pretty sure ours couldn't even tell you what the project were working on even does.
erm... its not scrum master anymore chuddy, its "agile lead" now
Scrum has the opposite effect in corpo land because you can actually get team approved slack time. My team always overestimated story points so I always had plenty of time to finish my tasks and no moronic exec asking every 5 seconds where the project is.
agile is the true way to build software
not JIRA agile, not agile + scrum, just agile.
>Individuals and interactions over processes and tools
>Working software over comprehensive documentation
>Customer collaboration over contract negotiation
>Responding to change over following a plan
https://agilemanifesto.org/
How stupid do you have to be to not understand:
1 - easy as frick
3 - maybe a day
5 - maybe a week
8 - more than a week
13+ - should be broken down to smaller tasks
Where I work it's:
1-3: 1 or 2 hours of dev and simple/no testing
5: still kinda easy to develop and test
8: probably a day o dev, some elaborate testing and some bug fixes
13: a little harder
21: somewhat harder
34: dios mio
55: sto-
89: aaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Your system is a little more complicated but it's relative anyways, as long as people try to put their points relatively right the velocity charts will be correct. The whole point is to have some transparency and have the project manager have some insight on who is struggling or having roadblocks. At least in my experience with a good project manager it was how they beat the morons who put in sprint bombs away.
I detest all those "tools". Especially the problem solving tools. If the problem can be solved with a problem solving tool then it is trivial and you could have just solved it by thinking. If you can't solve the problem easily then problem solving tools will not help you.
I worked at a company a while back that started scrum a few months before I left. Our sprint retro and point planning took 2+ hours every other week and planning poker regularly ran over due to people arguing about points.
What's wrong with waterfall? I know it gets a bad rap, but I feel like treating software engineering like physical engineering might lead to projects with actual standards applied.
Because 90% of the time your initial project is shit and not what customers want. So you benefit a lot from doing an MVP and rapidly innovating based on usage patterns. Waterfall projects tend to be monolith multi-year projects and you can't develop like that today with the pace of competition.
Maybe I've just worked with shit companies, but that rapid innovation seems to lead to fragile solutions with technical debt held together by bubblegum and paperclips.
I've only worked in "agile" teams thoughbeit, so this might just be a case of the grass looking greener.
How do they get away with it in non-software engineering? Is it just a matter of SWE's being pushovers for clients, while physical engineers will tell them to frick off or better define their requirements?
Because with non-software engineering you're talking about a lot people of many disciplines involved in a project which means you have to line up everything years in advance, you don't build a skyscraper willy nilly and there are many examples of companies going bankrupt because their project failing halfway through so it's not like waterfall saves them, it's just impractical if not impossible to do agile with a real-world engineering project. Of course in highly regulated software you have to do waterfall because you need to plan for and develop for legal requirements up front.
Your goal is to make a product ASAP that makes money, once you're making money you can properly redesign your software. The problem with waterfall if you don't know which part of your software is going to be what customers resonate with, you can waste 80% of your time on a set of features you throw away. I've personally seen this happen multiple times, often the thing you think will be making they money is the thing no one uses. Personally I think it's better to think of your software in one month feature chunks with some long term goals you're aiming for.
>How do they get away with it in non-software engineering?
I am luckily not involved with the part of my company that adopted agile shit but it is probably like our PLM software. Providers of the system sell it as looking really nice and being really great to the people up top. People up top eat up the presentation and buy the system. And then people who use the system suffer because system is bought and you have to use it.
no you got it. make up a random number then add a few more based on how poorly worded the description of the task is
It's shit, especially if you cannot pre-study in deep the ticket, the job will be done when it will be done and that's all.
I don't know but my score for the girl in the image is 10