Live data from Hacker News

Scrum is a cancer

twitter.com

131–140 of 486 posts

Re: Scrum is a cancer

#131

Most people don’t know some history. During 1990s, a group of people made a fortune out of consulting gigs where they will be called in by their CTO friends in traditional enterprises to save the late and over budget projects. One of these people was Kent Beck. Kent will use his license to kill to turn things around and eventually generalize his rescue formula and sell it to make 100X more. His crowning glory during…

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.

Re: Scrum is a cancer

#132

I'm honestly surprised to see a post with a vitriol-to-insight ratio so bent in favor of vitriol getting such a positive response. I think the poster here is way, way off mark. It's incredibly frustrating, because so many of the things he says suggest that he or his organizations truly don't understand scrum, yet he proactively goes on the offensive against anyone who suggests he's wrong and won't listen to any evide…

Testimony from dozens upon dozens of developers that think that scrum is useless, toxic bullshit: https://github.com/rayfrankenstein/AITOW/blob/master/README....

Data from lots of people who think Scrum is great and love it:

> https://www.parabol.co/resources/agile-statistics/#agile-eff...

It's the Internet. You can find a few thousand (or few million) people who love or hate anything.

What's your point?

Re: Scrum is a cancer

#133
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.

Re: Scrum is a cancer

#134

Then the individual goes on the dumber-than-life anti-communist rant. I love how he tries to create a bunker with "if you disagree you're into Scrum". I dislike Scrum quite a bit, but oh gee ain't that a full plate for Scrum apologists to have a point.

The individual was born in the unitary Marxist–Leninist one-party socialist republic of Cuba and lived there for a bit under three decades. He might have some expertise on the topic.

Re: Scrum is a cancer

#135

From 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…

What if the boss gets a wake up call from bank, saying they are out of funds to pay team salaries, first?

Re: Scrum is a cancer

#136
"Your software should be agile, not your process. Your process should be "disturb as little as possible". Either you code or you get out of the way and take responsibility for the people that code by slowing them down just enough to trust them."

Re: Scrum is a cancer

#137

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 think Scrum done well works rather well but retrospectives tend to be a lie.

Teams generally aren't allowed to stop doing sprints. In some places they aren't even allowed to pick start and end dates because management wants all teams on the same cadence.

If you use Jira - there's often all kinds of stupid imposed workflows. Mandatory fields depending on ticket types etc. If it's not useful to your team - tough shit, you don't have a choice.

Want to stop doing story points and use tshirt sizes? You can't, management monitors velocity as performance indicator.

Once you've had a few suggestions shot down because of top-down mandates, why even bother with retros?

Basically, scrum is very frequently a top-down management technique and teams aren't actually self-organizing because management can't deal with 10 teams each doing things their own way.

Re: Scrum is a cancer

#138
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…

>taking developers who can’t or don’t want to see the overall business/architecture picture and getting useful work out of them

That's a very charitable view... I think back over my career and it was always cargo-culting and micromanagement. I give you credit for analyzing and finding a way to make scrum work beneficially.

The thing is - if you have people who don't (want to) understand the relationship between their work and business value, you've fundamentally got a hiring / personnel problem. And I don't see how scrum (or any other methodology) ever solves that. What you've got at that point is to me the difference between "programmers" and "developers / engineers". People who are more enamored with the technology than with actually accomplishing work. The thing is, some of those people are really good so long as they can be pointed in the right direction. But that's a management thing, not really a methodology thing.

Re: Scrum is a cancer

#139
post #56

From 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…

While I too despise Scrum, the causation could be runming the other way: the Bosses that have a better team could be more likely to let them run without major pressure.

44 yo dev here. What I've seen from managers is that "letting go" is more of a personal trait than an external force.

Some people just have a very hard time letting go and trusting a team. Who they are managing just needs to follow.

Re: Scrum is a cancer

#140
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’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…

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.
Post reply on HN