Live data from Hacker News

Scrum is a cancer

twitter.com

251–260 of 486 posts

Re: Scrum is a cancer

#251

Earlier quoted context omitted.

There’s a pretty big difference between carefully seeding up and coming talent and deliberately hiring 40 mids like some folks are suggesting here to build their scrum teams or whatever. There aint going to be no growth here.

If you can determine an "up and coming talent" from a "mid" during a 1 hour job interview, you really should start up a HR consulting company. =) The only way to figure it out is to hire the ones that seem good and see who blossoms.

Yes which is why your strategy doesn't work unless you're also really good at firing people (which brings its own set of challenges).

Re: Scrum is a cancer

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

You're arguing that the entire system is invalid because one of the concepts is poorly named?

Re: Scrum is a cancer

#253

Earlier quoted context omitted.

All you said is true. But the number of talented programmers is very limited and concentrated. And they are quite expensive. Most companies and teams have to go the structured approach with whatever local mediocrity they can hire.

I disagree I guess and they are not as expensive as 4-5x more mids. > Most companies and teams have to go the structured approach with whatever local mediocrity they can hire. Yes most companies fail

Most people work in most companies that mostly fail over time. Making a living is the goal with work, building enduring value is something that few achieve.

Re: Scrum is a cancer

#254
The good thing about Scrum is that it introduces frequent moments of accountability. They are not popular but much needed in many teams and better than the alternative of the traditional waterfall approach.

It should also very frequently reveal issues. In misunderstandings, planning, underestimation, dependencies. This is a good thing as you can then course-correct early.

That said, it is soul crushing. Some jobs/tasks just don't fit into SCRUM yet one is forced to adhere to it anyway. There's way too many meetings. The boundaries of roles are not respected. Quality is not rewarded, only story point delivery. There's typically no feedback loop from users/the market as to whether actual value was delivered because you're working on the next sprint. Product owners are not actual owners. Scrum masters act as project management.

A typical scrum team easily costs 1M to run even here in Europe. And yet they produce so little. If you'd hire 3 A-class players in a high trust environment they'd produce 10 times more at superior quality.

True comedy is found in "scaled agile". This is where the SCRUM elite of the company get the teams together and ask: tell me for the next 6 months which stories you will deliver and figure out all the dependencies.

Mind you, near-zero input is given. You might as well roll a dice. And still we're all here to pretend that this insanity is normal. I no longer fight it.

I actually feel bad for business owners. They're setting on fire some 50-70% of their hard-earned revenue on talking and book keeping.

Re: Scrum is a cancer

#255
> We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention.

The ball feels a little gimmicky but otherwise in general I am in favor. The whole point of no laptops / standing / forced attention is to actually cut down on the meeting time by encouraging people to be present. When people can tune out and multitask, you get wasted meetings. If people are paying attention, they'll call out time wasting.

> I had to use t-shirt sizes to estimate software.

Why is this a problem?

> We spent more time estimating story points than writing software

This I just really don't believe. Perhaps it was meant in jest / hyperbole and does not actually represent a true accounting of time. If actually true, this is not a problem with scrum, but with your organization. Just because a process is misused doesn't mean the whole thing is useless.

> scrum is not for developers

Probably the biggest thing I definitely agree with. You know what else isn't "for developers?" The existence of the business itself.

Re: Scrum is a cancer

#256

Earlier quoted context omitted.

If you can determine an "up and coming talent" from a "mid" during a 1 hour job interview, you really should start up a HR consulting company. =) The only way to figure it out is to hire the ones that seem good and see who blossoms.

Yes which is why your strategy doesn't work unless you're also really good at firing people (which brings its own set of challenges).

Over here we have a 6 month probation, during which you can fire people American-style by just saying "GTFO" with no reason required. (You can give one, but it's an art to tell the correct one, the wrong reasons will get you in trouble)

Yes, there are some people who shape up for 6 months and then start slacking, but they're definitely not the norm. You should be able to evaluate a person in that time and see if their personality fits the team and whether they are a net positive for the productivity.

Re: Scrum is a cancer

#257

Earlier quoted context omitted.

Nice, though part of me wonders: if using version control why bother reading off yesterday's commits? Rest is pretty good and accurate imo.

"what they did yesterday and what they plan to do today" is not something you can read off people's commits "I was figuring out how to add a doohickey that widgets foobar" is not a commit, but during the daily someone else might remember that there already is something that can widget foobars. Or they might know that widgeting foobars was tried before and it failed because X and Y. Then they won't start debugging tha…

ACK

Re: Scrum is a cancer

#258
Lol, I was on a team that was required to stand during standups, even though we all sat together and could just swivel our chairs around.

One dev flat out refused to stand. I can still see the pulsing vein on the neck of the project manager who so wanted to scream ‘You will stand during the standup dammit!’

Re: Scrum is a cancer

#259

Lol, I was on a team that was required to stand during standups, even though we all sat together and could just swivel our chairs around. One dev flat out refused to stand. I can still see the pulsing vein on the neck of the project manager who so wanted to scream ‘You will stand during the standup dammit!’

> One dev flat out refused to stand. I can still see the pulsing vein on the neck of the project manager who so wanted to scream ‘You will stand during the standup dammit!’

There's no project manager role in Scrum so he was already doing it wrong.

Re: Scrum is a cancer

#260

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

we call them cycles (weekly cycles, or bi-weekly cycles, mostly they are product planning cycles, and also usually the basic time interval after the previous planing assumptions should be checked/revised, etc.)

// linear also calls them cycles, https://linear.app/features/plan#cycles , but linear is a bit meh

Post reply on HN