In my last company, when the idea of T-shirt sizing came up, I legitimately thought whoever mentioned it was joking. As if the rest of the excruciating processes, and petulant passive-aggressive behavior of my managers weren't patronizing enough. "Ah yes, now I get it, it's like clothing! I have some clothing right here next to me, now we're speaking a common language"
Scrum is a cancer
191–200 of 486 posts
Re: Scrum is a cancer
#192My experience with scrum is: metric driven development.
Not metric as in the measure of the effect of your code, but Jira (or whatever your task manager is) metrics. It systematize the process, without taking the actual work into consideration. This is why you get a "but you did the other similar project with just 50 points."
The metrics always win because developers end up working overnight to complete the project on time. So it validates the metrics.
My teammates message me when they find issues with their task. We discuss, hop on calls, involve other teammates, the works. But then on the daily stand up, we repeat the issue to the scrum master, even though this person could care less about the issue.
Scrum is a fantastic tool if your job involves making reports about the work being done. Except, it doesn't reflect the actual work being done. And my poor reader, you are probably not in a position where you can do something about it.
Re: Scrum is a cancer
#193From Peopleware: “In the 1985 Jeffery-Lawrence study [from the University of New South Wales]…they investigated the productivity of 24 projects for which no estimates were prepared at all. These projects far outperformed all the others…Projects on which the boss applied no schedule pressure whatsoever (‘Just wake me up when you’re done.’) had the highest productivity of all.” I read 20+ books on management and leader…
During a certain phase of my career, I was part of a company that extensively used the Scrum framework.
My takeaway then was that Scrum fosters a modular team management style, which diminishes the dependence on highly skilled individuals.
This approach seemed to offer management a sense of oversight in the software development process, but I didn't stay long enough to determine whether this was actual control and predictability or merely an illusion of it.
Re: Scrum is a cancer
#194From Peopleware: “In the 1985 Jeffery-Lawrence study [from the University of New South Wales]…they investigated the productivity of 24 projects for which no estimates were prepared at all. These projects far outperformed all the others…Projects on which the boss applied no schedule pressure whatsoever (‘Just wake me up when you’re done.’) had the highest productivity of all.” I read 20+ books on management and leader…
I re-read Peopleware this last weekend. It's one of my favourite books on the topic of software management. There are chapters that are not very useful for the $current_year (eg. regarding telephones or office furniture) but overall it's a fantastic piece on human interactions in the industry.
Re: Scrum is a cancer
#195Earlier quoted context omitted.
This, and more. Like it or not,the incredible success of software made it an industrial affair, the way clothing industry went 200 years ago - from highly skilled artisans creating unique beautiful designs tailor specifically to their customer to cheap patterns industrially printed. Its just that the printers are still human.
So sweatshops basically? Not sure it's a great analogy though since software is still basically the design part - the duplication part is trivial.
You do know that there are steps between bespoke tailor and exploitative sweat shop, right?
Multiple steps actually.
(And in some cases the alternative to the "sweat shop" is the same amount of hours outside in the fields with fluctuating income based on what happens with the crop that year)
Re: Scrum is a cancer
#196Earlier quoted context omitted.
> Our team gets publicly dinged if we "carry over" tickets between sprints This is not part of scrum
It kind of is. Well, the public dinging probably isn't. But at a few companies I've seen, teams are tracked on how many tickets span multiple sprints. If it exceeds some threshold, then theoretically it means that either: 1. The team is not breaking down tasks granularly enough, or 2. They're not estimating tasks correctly Practically, it means nothing of course.
In Scrum:
- the product owner sets the backlog priority
- team estimates
- team commits to what it can deliver from the backlog
- any misses are analyzed for scope mistakes
Rinse/repeat
There’s no shaming part
Edit: format
Re: Scrum is a cancer
#197I probably said it before in a previous post, but the problem isn’t scrum/agile per se, it’s just a tool, the problem is the inexperienced PM who thought just because it was applied in their previous company or another big tech, then it must be the secret formula for success, that, or as OP said, abused by control freak managers to micro-manage the team more, like poor soul I know, they had meetings for meetings..
I remember one time got in several conflicts with a manager who -again- is trying to copy-cat all these shenanigans like standup and what not even though neither the work nor the team nature fits that type of work, first, I wrote him that wasn’t the best approach and better to use these tools, second I tried to communicate that face to face, third, I actually applied these tools I was suggesting in a project I am doing as a way to show an example how it’s done maybe that will convince him, unfortunately, nothing worked with him, it was “my wrong way or the highway” approach, he wasn’t even certified PM with no training and I was, had to leave them after delivering my project.
Re: Scrum is a cancer
#198Two employees of a company were suddenly approached by the CEO accompanied by the CTO.
- Death or Scrum? - asked the CEO
The employees knew nothing about this Scrum thing, but were to intimidated to ask and the other choice was one they were not ready to make.
The first one thus replied in a quavering voice: "Scrum"
In this moment the first employee was grabbed by the CTO and was put through horrors not many could withstand:
- Neverending sprint planning meetings
- Daily Scrums that lasted 4 hours
- The sprint reviews
- Sprint retrospectives
- The backlog refinements
After all this the employee was only able to say: "Still working on User Story XYZ. No impediments."
The CEO then asked the second employee what their answer was. The employee was fighting a tough fight in their head.
"I hate meetings, I would love to do some real work, but I'm not ready to die yet. On the other hand, I can't go through life after all that abuse; There's no way I could live with myself". So he answered: DEATH!
To this the CEO swiftly replied: Death ... by Scrum
Re: Scrum is a cancer
#199Earlier quoted context omitted.
https://news.ycombinator.com/item?id=37134050 > Not everybody knows that, but Scrum was invented to manage a team of dysfunctional COBOL programmers at a bank, not for product-led tech companies, and certainly not for startups. > If you're mostly hiring juniors, low-skilled, unpassionate, unable to work autonomously without constant handlholding, reactive instead of proactive people, then you'll certainly need some m…
So funny thing... about twenty years ago I was managing a project with Cobol developers on one side, and this web thing on the other. And we had a bunch of business people convinced we were all stupid and lazy, so they wanted to force us to do this scrum thing. We would do things like a daily standup with them in order to go through the motions, and then we'd have the real meetings once they left us alone. Because th…
> and the business people took credit for it and I got overlooked for promotion and life went on.
Story of my life! And I guess it is the case for most competent employees unfortunately.
Re: Scrum is a cancer
#200I’ve developed a more nuanced view on Scrum since working as a contractor for a medium sized software company, but adjacent to their normal dev teams. I used to have the view that Scrum is a useless batch of meetings, that sucks the life and productivity out of the dev process. Now, after seeing it from an adjacent (but not subjugated under it) perspective, I think it is a life-sucking batch of meetings that are good…
> I’d argue that you’re way better off hiring 6 devs that can go from business problem -> technical solution in their head, without all the ceremony, instead of 40 devs who can’t and 6 PMs to wrangle them. The problem is that finding those 6 experienced devs is _HARD_. And they're usually very expensive and know their value. You can easily find 40 mid to low level coders and a half-dozen people who know how to run a…
> The problem is that finding those 6 experienced devs is _HARD_. And they're usually very expensive and know their value.
That’s not the only cause with all due respect, I have worked with several C-level managers before, they WANT those mid-low level developers/engineers, they are cheaper and easy to find like you said, but most importantly, they can replace them on a whim with another one who will do the same work, with “super” engineers, it isn’t the case, the amount of knowledge and depth one of them has, you will need a whole team to understand what’s going on first and another to carry on the job, and C-levels being egoistic, they don’t like anyone to have any leverage by any means.