Live data from Hacker News

Scrum is a cancer

twitter.com

211–220 of 486 posts

Re: Scrum is a cancer

#211

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…

I think the biggest risk to scrum as a methodology is the fact that when it so frequently fails, its defenders constantly fall back on "but that wasn't true scrum". Like, that's 90% of all the posts here defending scrum. Yet the things this guy describes are recognizable to many of us, perhaps it's an extreme case but not that extreme.

Re: Scrum is a cancer

#212
post #112

I'm going to get blasted for this, but you *are* doing scrum wrong. Scrum was invented by engineers to defend themselves against incompetent middle managers. The moment you let management take the process over and warp it you are already doing it wrong. Story points and sprints are a *self-calibrating* tool that will give you an advance warning (nicely visualized in burn-down charts) if an estimate you might have giv…

> Story points and sprints are a self-calibrating tool that will give you an advance warning (nicely visualized in burn-down charts) if an estimate you might have given a middle manager will be missed. > You do not "decide" how many points fit in a sprint, you just work at a sustainable pace and measure how many points fit in a sprint. I don't know how you can use both "sprint"[1] and "sustainable" in the same post w…

This is turning into a discussion about naming, which is important. I think the sprints are maybe wrongly worded, but I struggle to find a better term.

User stories are not actual stories with a plots as well, but the idea makes sense

Re: Scrum is a cancer

#213
post #184

Earlier quoted context omitted.

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

> > 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. It's harder than finding uncaring juniors, sure. But if you need 40+6 people, or 6 experi…

The problem is that I'm not talking about Silicon Valley, it's an anomaly within an anomaly when it comes to hiring.

I'm pretty sure that short of John Carmack or a legend of that caliber I can't justify paying 1M to _anyone_ to the people making the budget.

Of course you can grab a half dozen superstars if you pay them a million per head, but they'll also leave the second the job stops being 100% interesting.

That's not a sustainable way to build a company or a team.

Re: Scrum is a cancer

#214

Earlier quoted context omitted.

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

> Also in the latter way you can easily have a turnover in the team without any major hassles, you can always find mid-tier coders. And turnover you will have! =) Note that you just ballooned the cost probably 3-4x compared to keeping the team small and strong. And that is how we got to this zombiecorn land we see today. Also consider this - hiring a large team of bozos is a one-way street. You will likely never be a…

One thing to remember is that every superstar used to be a mid-tier coder. This is not an YA novel where talent is decided at an arbitrary time and that's the lane you'll hold until you retire. =)

When you hire people straight off school or "mid tier" people, you can help them grow to be better and reap the benefits.

If everyone will just hire the "top tier talent", their prices will inflate and the pool of top tier people will never grow.

Re: Scrum is a cancer

#215

Earlier quoted context omitted.

> Story points and sprints are a self-calibrating tool that will give you an advance warning (nicely visualized in burn-down charts) if an estimate you might have given a middle manager will be missed. > You do not "decide" how many points fit in a sprint, you just work at a sustainable pace and measure how many points fit in a sprint. I don't know how you can use both "sprint"[1] and "sustainable" in the same post w…

This is turning into a discussion about naming, which is important. I think the sprints are maybe wrongly worded, but I struggle to find a better term. User stories are not actual stories with a plots as well, but the idea makes sense

Maybe, but the people you are telling the word "sprint" to do not interpret it as "iteration" or "phase", they are interpreting it as "unsustainable burst of speed".

When you tell people the word "story", they know exactly what you mean, because the word story is used all the time for things without plots ("So, what's your story?" comes to mind).

We frequently use the word story to mean "your side of things"; in civil litigation for example.

Re: Scrum is a cancer

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

Most companies want to minimize salary while managers and directors are highly incentivized to maximize headcount. It’s very perverse.

Re: Scrum is a cancer

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

The reply to that comment is also valid, IMHO

Re: Scrum is a cancer

#219
post #75

Earlier quoted context omitted.

Kanban is one alernative[1] [1] https://en.wikipedia.org/wiki/Kanban_(development)

My question is - how DO you convince management to let you try Kanban? We would like to try but we can't, as "everyone else here does Scrum so the problem is in you, not in the process".

In my case, it was a few managers in the org who decided to change over from scrum to kanban.

If there are some teams in your organization or company using kanban, you can use them as an example. If issues brought up in the retrospectives are not being addressed and those issues are related to the scrum process, then that might be a way to get something to change.

Re: Scrum is a cancer

#220
Don’t blame scrum/agile for bad decisions made to appease business executives. A product owner’s role is to seek input from stakeholders and then make decisions to satisfy those stakeholders and the company’s business directives.

Companies were making poor technical decisions for short term business reasons long before agile became popular.

The cancer you seek is actually called capitalism.

Post reply on HN