Live data from Hacker News

Scrum is a cancer

twitter.com

421–430 of 486 posts

Re: Scrum is a cancer

#421
post #350

I’ve had good experiences with scrum. I was on a team that was empowered to own and refine its practice. We were able to halve our cycle time and improve sprint planning to the point where we rarely overcommitted. It was great, and it was credited with the successful delivery of a major project. Unfortunately, our management changed, and we were no longer empowered. The new manager had his own ideas for how things sh…

> That’s really my biggest issue with agile. There’s a big focus on process, but it’s about the people

From the Agile Manifesto: Individuals and interactions over processes and tools. What you described doesn't sound Agile by the book.

Re: Scrum is a cancer

#422
post #274

In one of my previous projects I lead a team of 5 talented and creative people and we did truly agile programming: everyone helped each other, asynchronous meets as needed, spontaneous pair programming, direct access to the customer (who also happened to be technical people with a clear picture in mind)... Truly a joy of a team to lead, because they really lead themselves :) However, the management insisted that we a…

> I objected to this and listed all of the problems I could see if Scrum was introduced: losing dev creativity and incentive, tickets taking exactly one sprint to complete instead of doing them at leisurely pace, the mistranslation coming from having one extra layer of communication (Scrum Master handling the client now). And that was your big mistake. Those are real concerns, but those things are abstract and non-qu…

The proper way to fight scrum is simply doing scrum properly.

Nobody usually wants this.

For developers scrum is actually quite nice. The main success metric is predictability, i.e. the team is held accountable for delivering the sprint successfully. Which means you're supposed to be left alone while the sprint is ongoing.

Some bug? Pfft, if not critical, will maybe take it next sprint.

Finance needs a new report, pronto? Sure, let's talk about business value for priorization. And earliest next sprint anyway.

CEO has a crazy idea that he wants somebody to pull off? Sure, but please talk to Product.

What do you mean, you need more story points delivered per sprint?

The main issue is there are actually people that thrive in this kind of bureaucrazy. I've seen a number of 20-something POs burning themselves over these shitty processes.

Re: Scrum is a cancer

#423
post #420

Earlier quoted context omitted.

Our 15 minute standups were about an hour, sometimes longer. The project manager aka scrum master spent at least 80% of those minutes talking. They were scheduled for 11:30am, right when everyone was either wanting to go to lunch, or for people not taking lunch probably the most productive middle part of the day. For those who went to lunch afterward, they never got to start before 12:30pm, and were out to at least 1…

So it wasn't scrum. It was just bullshitters using the word and doing what they wanted to do anyhow.

No True Scotsman?

Re: Scrum is a cancer

#424
post #381
post #374

Earlier quoted context omitted.

> The proper way to fight scrum is to measure the time it takes to perform the scrum 'ceremonies'. It's rarely less than 30% of the total work time in a sprint. 50% seems to be very common. I do not understand how this is possible. * Sprint planning: 2 hours * Sprint review: 1 hour * Sprint retro: 1 hour * Daily stand-up: 15min / day On a 2 week sprint, 80 hours, that's 5.5 hours spent on ceremonies. That's ~7%. What…

At my previous job, the "daily stand up" never lasted less than 30min, and often times went to 2 hours. Also, I didn't just have one "daily stand up" but two! One with multiple teams, and one with just our team because our manager really wanted to silo our work and ignore as much as possible other teams (especially QA for some bizarre reason). Yes, we weren't doing "scrum" right, but like communism, no one does it ri…

We manage short standups most of the time - why didn't you tell the manager to shut down after 15 minutes? All these agile processes require the team to take some responsibility and have some courage.

Re: Scrum is a cancer

#425

This guy is a grifter with uninformed, ranty opinions, and it's a shame he is getting so many of these HN eyeballs for his purposefully provocative nonsense. Here's my more comprehensive post the last time this was raised: https://news.ycombinator.com/item?id=37289151#37290237 The TL;DR is that he's just making unsubstantiated angry ravings and being treated like he's saying something meaningful because there are peo…

I'm not going to provide a source, but I bet a lot of developers can relate to what he said. It feels like a lot of us have had Scrum shoved down our throats at some point or another and it feels great to finally lash out.

Re: Scrum is a cancer

#426
post #378

Earlier quoted context omitted.

Have you ever seen the movie Office Space? There’s a bit about “TPS reports” where multiple managers individually correct the main character on a new cover sheet. I’ve experienced that myself. The movie portrays it comedically but IRL it’s kind of a demoralizing experience. A bit soul crushing actually.

I haven’t seen it yet surprisingly. I will watch it tonight.

You absolutely must. It was great when it was new, it's even better now.

Re: Scrum is a cancer

#427
I think rapid iteration + kanban style documentation is indispensable towards good productivity for most dev teams. I think having quick dev cycles + good documentation benefits everyone: devs, managers, and the accounting team too. Where I think Scrum goes wrong is that turns documentation+rapid iteration into a cudgel to use against devs and pressure them.

"Why didn't you finish this story? You committed to us you'd finish in two weeks!!" Perhaps well documented rapid iteration processes naturally tends towards dev mistreatment, but I genuinely hope not.

My dream world is where devs can aim high, fail, and try again as many times as is needed without being judged/penalized.

Re: Scrum is a cancer

#428
post #340

The good thing about Scrum is that there are hundreds of little dials that can be modified if you're not getting any value from it. Due to this level of flexibility, it's always the right approach.

Isn't that precisely one of the most glaring issues with Scrum?

Scrum tries to provide a measure of velocity in such a subjective manner, it is not useful to anyone involved.

Re: Scrum is a cancer

#429
post #415

Earlier quoted context omitted.

What's the difference between what you're talking about and scrum? IMO the conferences are really there because the way companies think about projects and plans is not agile and it's difficult to marry up the higher level decision making with the way that agile makes decisions much faster. I don't think there has really been a solution to this. Agile roughly says that if you find out that what you're doing is stupid…

Scrum is a strictly defined process, it has Scrum Masters, Product Owners, certifications, books, a number of defined meetings, sprints... Sort of the opposite of agile. > Agile roughly says that if you find out that what you're doing is stupid or impossible then change and do something that will work Exactly. But with Scrum, if devs complain it's not working, the certified Scrum Master will just say what you're doin…

Scrum includes retrospectives - they exist to change the process. If the process cannot be changed then it's not scrum.

OTOH when you're starting out it takes some time to find out what works and a scrum master will probably want to make you try to stick to the basics until you've given them a chance. Most people cannot see the point of one part or another until it has helped them personally once. After a while the team should be able to have a rotating scrum master - one of the team for a sprint.

Re: Scrum is a cancer

#430
Scrum fails when it is formalized and run Cargo-Cult style. "We must do all of these steps as in The Book." If you understand the reasons for the steps, and instead incorporate the function in the day-to-day activities, values, and norms of the team you get the benefits with very few drawbacks. But yes, you're no longer a "true Scotsman" doing "real Scrum."

Consultants suck the meat off the bones and resell the skeleton, then management wonders why the specimen doesn't appear to be the genuine animal.

Post reply on HN