Live data from Hacker News

Scrum is a cancer

twitter.com

141–150 of 486 posts

Re: Scrum is a cancer

#141

Earlier quoted context omitted.

This is a No True Scotsman argument. The guy enumerated a list of ways scrum failed in his experience; it's always interesting to hear honestly about failure modes from people who have actually used something a lot in their work.

It's interesting to hear about failure modes, and anyone whose job it is to teach stuff like this is interested in hearing about failure modes. It's the taking of one person's experience and extending it to encompass everything that's wrong. Obviously the people charged with implementing this in OP's company are doing it wrong. That doesn't mean it's OK to insinuate that everyone who ever tries to implement Scrum or…

> For every clueless toxic manager who doesn't understand how to use Agile correctly

Anecdata Of One: I have worked at many places since 2005 and the most successful projects have been those without any Agile[1]/Scrum imposed by management. In contrast, the places with the worst outcomes[2] have all had distinct Agile/Scrum imposed by micro-managers[3].

[1] Plenty of places with iterative development but solely due to the nature of the work (changes required by external QA, experiments, etc.), not imposed.

[2] Software quality and speed of development-wise. They're all still alive and limping along despite the horrific nature of their internal systems.

[3] Who have always been there in a place with Agile/Scrum. Only once in a place without. I don't think it's coincidental.

Re: Scrum is a cancer

#142

I have a lot of issues with scrum and I think twitter post and the comments here touch on a lot of them, but one of my biggest annoyances with the whole thing that I hardly ever hear anyone mention is the term "sprints". If you asked a marathon runner how to run a marathon, they're going to tell you things like run slower, make sure you conserve energy, and control your pace. They're not going to tell you to mentally…

From “Agile In Their Own Words”, https://github.com/rayfrankenstein/AITOW/blob/master/README....

“One aspect of agile, and of SCRUM in particular, is that the team is expected to 'forecast' which stories it will 'burn down' for a sprint. The phrase "forecast" is often replaced with "commit", and a manager-type will interpret this to mean he/she gets a fixed price deal with the team, yet without any quotation on behalf of the team for assessing risks/opportunities, as with a regular fixed price contract. As a freelancer, you can't let this happen, so it leads to unpleasant discussions.

I also take issue with the term 'sprint'. By definition, a sprint is a short-term sports activity to reach a goal in the shortest amount of time possible. But just as in sports, you can't expect to do one sprint after another without quickly burning out, and that's exactly what I've been seeing in agile projects. An engineering-heavy software project shouldn't be seen as a series of sprints at all, but more as an endurance run if anything.

I also hate the term 'agile' itself, which seems to be chosen to appease to a manager's idea of interchangeable, faceless staffing. Actually, "agile" makes me think of spermatozoa striving to fertilize ova.

I also despise the motivation propaganda that usually goes with agile, and the "scrum masters" non-coders interrupting any meaningful technical discussion they don't understand and suggest to take the discussion 'offline' or 'time-boxed'."--imhotap, https://www.reddit.com/r/programming/comments/6rsyrd/in_a_nu...

Re: Scrum is a cancer

#143
post #46

I’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…

It works both ways. Every form of micromanagement will turn every dev team into a bunch of demotivated, junior performing, just here for the paycheck careless bunch of codemonkeys. It is an assured loss for all. Why not the opossite way? Trust people a bit above what they currently warrant, see who rises to the opportunity, and ease out the rest. This will over time elevate to a decent team.

The Netflix Culture deck[1] acknowledges that this strategy requires "top of market compensation." What percentage of organizations have the ability to pay top of market compensation? The answer to that is the reason why the strategy doesn't generalize.

1. https://igormroz.com/documents/netflix_culture.pdf

Re: Scrum is a cancer

#144
post #46

I’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 have been slaving as a cheap outsourced labor in a poor country for a large US software company. The goal of the scrum manager was specifically to prevent code monkeys from asking questions about "business/architecture picture" and to specify the tasks as narrow as possible. Anyone who asked too many questions was seen as a threat, as if they were going to communicate directly with our US masters and break the command chain.

Re: Scrum is a cancer

#145
post #46

I’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…

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 the problem wasn't that the Cobol programmers were dysfunctional, it was that the business refused to actually listen and understand anything - they just wanted to make edicts, even when they didn't understand the regulations or processes in their own business (this being a highly regulated industry...). I pulled off what was perhaps the first project in that company's history that got delivered on time and met its requirements (and it was a big flipping deal of a project...) and the business people took credit for it and I got overlooked for promotion and life went on.

Re: Scrum is a cancer

#146

I have a lot of issues with scrum and I think twitter post and the comments here touch on a lot of them, but one of my biggest annoyances with the whole thing that I hardly ever hear anyone mention is the term "sprints". If you asked a marathon runner how to run a marathon, they're going to tell you things like run slower, make sure you conserve energy, and control your pace. They're not going to tell you to mentally…

From “Agile In Their Own Words”, https://github.com/rayfrankenstein/AITOW/blob/master/README.... “One aspect of agile, and of SCRUM in particular, is that the team is expected to 'forecast' which stories it will 'burn down' for a sprint. The phrase "forecast" is often replaced with "commit", and a manager-type will interpret this to mean he/she gets a fixed price deal with the team, yet without any quotation on behal…

Another from “Agile In Their Own Words”

“My experience shows that proper testing and documentation is the first thing that management wants taken out of the story, often with the excuse "We can handle that in a later sprint." But since your life is a neverending series of sprints (note: that's actually an ultramarathon), and management gets to pick priorities, you may never return to the technical debt.”—klyrs, https://news.ycombinator.com/item?id=20017854#20021832

Re: Scrum is a cancer

#147

I would have guessed more HN readers would attempt to understand the desired outcomes, how the implementation attempts to achieve them, then take the good from the bad as a source of constant improvement. The tone on this thread has that jaded and defeatest "management sucks" attitude that I find most often in the least productive engineers regardless of how they work.

The guys here come to the scrum retrospectives, stay silent the entire time, and then complain that scrum sucks.

I've spoken up in many retrospectives, but when nothing changes, it's hard to take them seriously. What's the point of a retrospective if your feedback is simply discarded?

Re: Scrum is a cancer

#148

Earlier quoted context omitted.

What's wrong with TDD

If you don't already have a clear spec for what your code needs to do, it's essentially doubling what you need to code for no real gain.

I'd argue the opposite:

If you already know _exactly_ what your code needs to do, you can "just implement it".

I find TDD to be very helpful in the cases where I do _not_ know everything in advance, because it lets me take small steps to explore things and I get very fast feedback if I "misstepped".

Re: Scrum is a cancer

#149
post #46

I’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 think it is a life-sucking batch of meetings that are good for one thing: taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them.

If I'm being onboarded at some project, I expect to be provided that description as early as possible. Compensating for broken communication by enforcing a life-sucking batch of meetings doesn't seem right.

Re: Scrum is a cancer

#150

Earlier quoted context omitted.

From “Agile In Their Own Words”, https://github.com/rayfrankenstein/AITOW/blob/master/README.... “One aspect of agile, and of SCRUM in particular, is that the team is expected to 'forecast' which stories it will 'burn down' for a sprint. The phrase "forecast" is often replaced with "commit", and a manager-type will interpret this to mean he/she gets a fixed price deal with the team, yet without any quotation on behal…

Another from “Agile In Their Own Words” “My experience shows that proper testing and documentation is the first thing that management wants taken out of the story, often with the excuse "We can handle that in a later sprint." But since your life is a neverending series of sprints (note: that's actually an ultramarathon), and management gets to pick priorities, you may never return to the technical debt.”—klyrs, https…

Another from AITOW

“I regularly ask ‘Why are we running a marathon in a thousand sprints?’.

Besides tech debt, a concern I have that I don't see brought up is burn out. With Scrum, every action you perform is micromanaged and with a push for ‘high velocity’. There is no proverbial breathing room in this where the pressure lets up. At least with waterfall (for how we did it before Scrum), the windows of high pressure times were shorter. During the beginning of our 6 month waterfall, in parallel to spec work we'd be taking care of tech debt or implementing our pet feature and it was a time of mental recovery.”—epage, https://news.ycombinator.com/item?id=20017854#20021832

Post reply on HN