Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Scrum is a cancer

twitter.com

Post reply on HN
Print view View original

161–170 of 486 posts

Re: Scrum is a cancer

#161

Post by hiyer »

foogazi wrote: post #44
zug_zug wrote: post #13

Interesting phenomenon happens at my place which is scrum + Safe. Our team gets publicly dinged if we "carry over" tickets between sprints, so if we finish our work with 2 days left the manager asks not to start anything new. The process is a performance within a performance, literally getting told NOT to do more work. This is what happens when you have chart-oriented-development (particularly jira's toxic charts). Y…

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

Re: Scrum is a cancer

#162

Post by namaria »

dilyevsky wrote: post #152
theshrike79 wrote: post #79

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…

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.

Re: Scrum is a cancer

#163

Post by musicale »

Spiwux wrote: 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…

> bad management and bad engineers without any agency.

bad management destroys agency

Re: Scrum is a cancer

#164

Post by RayFrankenstein »

xedrac wrote: post #124
beardedwizard wrote: post #67

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.

I'll be the first to admit that managing a complex project's timeline is not a skill of mine. All I know is that the franken-scrum monstrosities that I have been subjected to in various organizations have all had a very negative impact on my morale and productivity. The problem I see is that the the business will want to make tradeoffs that the developers may not like. How you reconcile the two without hurting morale…

My problem is not whether I “like” management’s tradeoffs they force me as a developer to make; my problem is that managements typically don’t take accountability for choosing to make them.

And then management (and their allies in the closely aligned “Software Craftsmanship” movement) blame the developers for the consequences of those tradeoffs and all the technical debt that typical entails.

Re: Scrum is a cancer

#165

Post by floppiplopp »

Personally, I've experienced scrum only as a tool used by middle managers to control developers. It sounds good in theory, but power structures are a thing, and it gives too much influence in the way of metrics to malicious managing types who want to be in control. Scrum and agile are now red flags for me.

Re: Scrum is a cancer

#166

Post by lispm »

superfrank wrote: post #102

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…

If the word (sprint) is a problem, then change it. Call it "iteration", "segment", whatever.

Taking a 500km bicycle ride from one place to another, you surely will plan the thing as segments. I would plan days and see where I can reach milestones: a city, a place to stay, a sight-seeing place, a mountain top, a ferry, a destination...

A software development project of several months is not a Marathon.

I've run a Marathon in a few hours. But even in a Marathon I look at my starting preparations of the day, my 5km times, reach the half marathon, plan for the drinking stops, plan when my primary energy source is depleted, how to get over it, ... Few people run a Marathon from front to end with the same speed&energy, without a plan how to mentally split up the race.

Re: Scrum is a cancer

#167

Post by marcus_holmes »

kuchenbecker wrote: post #159
marcus_holmes wrote: post #118

Earlier quoted context omitted.

Not if you can't work on anything without a ticket, and you can't add a ticket to the current sprint.

Do it anyway, file the ticket and pull it into the next sprint.

So stop following Scrum? Completely agree

Re: Scrum is a cancer

#168

Post by dilyevsky »

wqtz wrote: post #127
theshrike79 wrote: post #79

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 have been taking a closer look at project management and product management in the last few months. Coming from the programming side, I thought technical product manager rule the world, and thought everything that is technically led is glorious. Then I had a very personal conversation with hardcore project manager from non-tech side. He told me that, I got the idea of management of all wrong. Project manager is an…

> Project manager is an operator where the engineers are nothing more than machine. Your standard engineer is not interested or even care about business goals. They are doing a job, they like to be told what is expected from them, they like to be told what deliverable is. Senior engineers can give an estimate of delivery date, but most don't. They are essentially cogs in the machine and managers are expected to birth products from them.

Yes I think you got to the crux here - managers want to be indispensable and make everyone else "a machine" so he told you a bunch of self-serving bs. I'm sure if you turn this around on him then project manager will not be a machine but more like a wizard or an artist whose needs must be carefully tended =)

> Moreover, you don't want programmers interested in business side as they get passionate about things that don't concern them which is obviously business side things.

Right and who is better to help here than someone who can take business requirements and hand them to the engineers? You know, someone who got people skills!

Re: Scrum is a cancer

#169

Post by _19qg »

hliyan wrote: post #70
computerdork wrote: post #57

I hope people read this person's full post. he says, "I believe in Agile, but this ain't agile." Yeah, agile and scrum aren't the same. In my humble opinion, agile process is pretty fantastic and a lot better than waterfall (although waterfall has some elements that should be carried over to agile) or even Rational Unified Process. Yeah, Agile is taking over the engineering world (not just software) for a reason, bec…

I once blew a team's mind by this simple demonstration: 1) Searched the entire agile manifesto site for "sprints", "stories", "velocity", "stand ups" etc. Zero references. 2) Searched the official scrum guide for the words "agile", "stories", "story points". Zero references. It only defined sprints.

https://agilemanifesto.org/principles.html

Read through the principles and then find out how it maps to scrum.

Scrum is not the same as "Agile", but it tries to provide a simple methodology to implement parts of it.

> continuous delivery of valuable software

> Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

That's a sprint in Scrum.

> The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

A stand-up is one way to do it. Standing and talking face to face may seem foreign to people used to sit all day in front of computer screens, but I think it's worth trying... ;-)

and so on.

Re: Scrum is a cancer

#170

Post by usr1106 »

bonestamp2 wrote: post #26
j45 wrote: post #4

Earlier quoted context omitted.

Is there an alternative anyone would recommend. It might not be the best question to ask given the complexity of the software and experience/culture of the team.

We do a very loose agile process and everyone seems to like it. Basically, we have a standup every morning. Each team member has up to 1 minute to list (in very brief form) what they did yesterday and what they plan to do today. It identifies if anyone will be stepping on anyone else's toes, or if anyone knows of something similar and can point you to it, and it lets the project manager know if anyone is working on s…

A standup every morning?

To my experience 10% of software developers think 7 am is morning, 60% something between 9 and 10. 30% not before 11 or 12. The first and the last group tend to be the most productive ones.

Forcing all of them to meet at 10 or even 9 is the best way to kill motivation and foster cynicism about useless meetings and processes.

Post reply on HN