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

221–230 of 486 posts

Re: Scrum is a cancer

#221

Post by xinayder »

I went on a road trip with my coworker last week. We were together and he had to attend to a retrospective meeting that was planned to last for 2 hours or so. The stand-in scrum master (their original SM was on vacation so someone stood in) said this would be an unusual retro because they had done 6 or 7 sprints and never did a retro on each of them.

I am in another section and we have retro meetings but they take 1 hour or less. Anyways, what caught my attention was two very stupid things introduced by their scrum master:

- estimating story points for completed tasks: they went over each ticket that was marked as done and asked how many days it took to complete the task. Me and the others on the car couldn't believe what we were listening to.

- making JIRA tickets for useless things like "how to install software X". We have a guide on Confluence with instructions on how to install said software and if you follow the guide from start to finish you can get it working and it shouldn't take more than 20 minutes. If, for some reason, it doesn't work, you can simply contact the author of the guide and ask them for help.

This is not what happened in my colleague's team. They had to create a JIRA ticket to track individual progress on installing the tool. I talked to this other colleague that created the guide and he said he was almost pulling his hairs out because he had to spend more than 2 hours debugging and troubleshooting with the people that apparently can't read a step-by-step guide on their computer. And then later they had to mark a JIRA ticket as completed.

This is very stupid and when I see this colleague of mine suffering with someone that is evangelizing SCRUM as any other meme scrum master out there just makes me hate it even more.

Re: Scrum is a cancer

#222

Post by deely3 »

xinayder wrote: post #221

I went on a road trip with my coworker last week. We were together and he had to attend to a retrospective meeting that was planned to last for 2 hours or so. The stand-in scrum master (their original SM was on vacation so someone stood in) said this would be an unusual retro because they had done 6 or 7 sprints and never did a retro on each of them. I am in another section and we have retro meetings but they take 1…

I'm not sure whats wrong with second point. Even with super-b detail guide you sometime get troubles/issues/errors that you unable to fix without outside help.

> If, for some reason, it doesn't work, you can simply contact the author of the guide and ask them for help.

> he was almost pulling his hairs out because he had to spend more than 2 hours debugging and troubleshooting with the people

Irony? Irony..

Re: Scrum is a cancer

#223

Post by red-iron-pine »

theshrike79 wrote: post #214
dilyevsky wrote: post #152

Earlier quoted context omitted.

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

"don't hire a 10x team, learn to build a 10x team"

or something like that.

Re: Scrum is a cancer

#224

Post by majikaja »

theshrike79 wrote: post #213
jjav wrote: 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. 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…

In Japan they are struggling even to find juniors because of the declining population.

Re: Scrum is a cancer

#225

Post by kelnos »

The level of scrum-apologism here is I suppose both unsurprising but also egregiously sad.

Scrum is garbage. Most software development methodology is garbage. And even if there are theoretically-good ones that are "only" garbage because people "implement them the wrong way", that too is the methodology's fault. If something is so hard to implement that most people get it wrong, with disastrous results, then that thing is indeed garbage, regardless of its merits when "done right".

We apply this principle to technical process: if someone manages to delete the production database, it's probably not that person's fault, but the fault of the processes around access controls and incident response. If everyone implements scrum catastrophically wrong, that's scrum's fault.

Re: Scrum is a cancer

#226

Post by kelnos »

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

> But if you’re trying to make a process than can take junior devs (not junior in tenure, but junior in the qualities above) and produce an output that scales almost-kinda linearly with dev count, it sort of works.

I don't think that's even the case. I've been brought onto teams of junior (in the sense that you talk about) developers to help fix broken, late projects. Those projects had always been managed under some sort of agile process, and they still ended up in trouble. I wouldn't even say the process "sort of" worked before then. I dunno, maybe it would have been even more of a disaster without the process, but I still don't think that lends much praise to the process.

I'm lucky that I can pick and choose what sort of projects I work on these days, and I will never work at or for a company where I'd be subject to any kind of agile garbage. Another toplevel commenter farther down mentioned a study that showed that projects managed under the "get to work and let me know when it's done" model outperformed all the others. I've always intuitively believed that model can work (though perhaps not in all situations with all types of developers), and it's nice to see some data to back that up.

Re: Scrum is a cancer

#227

Post by kelnos »

fendy3002 wrote: post #73
intelVISA wrote: post #61

Earlier quoted context omitted.

No love for Scrum but this is the more likely explanation. A good team that runs itself? Ofc it doesn't need Ten Scrum Masters to deliver value. Now, the real question is why leadership tries to salvage failing teams with Scrum? Save the wasted money, use it to hire top talent instead... easy.

If CEO can hire a 100$ scrum master to save a 1000$ failing team, it's much cheaper than hiring 2000$ successful team. That's probably what they're thinking

I don't think that's true at all. If there's time-to-market pressure (for example), then you really want that $2000 team to deliver on time. "Saving" the $1000 failing team with a $100 scrum master may not be good enough.

Also, please at least acknowledge that your numbers are completely made up and may have no basis in reality. It might be a $1000 team only if they deliver on time, but the overages might push that to $5000. Or whatever. See, I can completely make up numbers to support my point too.

Re: Scrum is a cancer

#228

Post by bjourne »

Writing software is more like writing books more than anything else. So any process that presupposes that the workload can be divided among roughly equal agents is bound to fail. That's my experience after two decades as a software engineer. Every good software team has two or three engineers who knows how to write books, how to structure a story, and can work towards a common vision. The rest of the team more often than not consists of tag-alongs that don't know nor care about good literature. Every good software project lets these two or three engineers get stuff done. Every bad software project suffocates these engineers with processes and/or makes them quit.

Re: Scrum is a cancer

#229

Post by PeterStuer »

kelseyfrog wrote: post #143
PeterStuer wrote: post #133

Earlier quoted context omitted.

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

I don't see where the document you cite makes this causal link. In my experience this is also not true. You pay enough for money not to be a concern. Then people start to value other things, such as not getting depressed through being micromanaged or killed by process.

Re: Scrum is a cancer

#230

Post by bdlowery »

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…

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 micromanaging SDLC like Scrum.

Post reply on HN