Live data from Hacker News

Scrum is a cancer

twitter.com

441–450 of 486 posts

Re: Scrum is a cancer

#441
post #431

Earlier quoted context omitted.

No True Scotsman?

That argument can be used either way around so it's fairly useless. In reality we don't have good software development because people at some level or another don't want to do the things that make it possible. They're always going to pretend they care but do what suits them. It can be from the most basic thing: the customer doesn't want to pay what it really costs to get something good but can be made to pay for some…

> n reality we don't have good software development because people at some level or another don't want to do the things that make it possible.

If you're confessing that it's contrary to human nature and/or the engineering thought process, then I humbly accept your concession in this debate.

Re: Scrum is a cancer

#442
post #292

Earlier quoted context omitted.

The meetings are good. You're getting paid during them. I managed to customise my bike, plan two international adventures, run a side business and do a year of a degree in pointless meetings in the last 5 years!

Yep. I have come to love Scrum for the dysfunction it provides as a remote employee. I can sit in the background and do other things while not being expected to achieve anything.

Eyes are watching. Your manager is likely to bring up that you're not an active enough participant in meetings; and yes, it will count against you in your performance reviews.

Re: Scrum is a cancer

#443
post #429

Earlier quoted context omitted.

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

In my experience, the best you can hope for from retrospectives is small tweaks. The length of sprints, how standups should go, who writes what in tickets.

But you can't change the process to be not-Scrum.

Once a company has decided "we do Scrum", you can't argue in retrospectives that sprints are completely artificial and unnecessary for the project in this phase, or that things would go much smoother if devs talked directly to the customer instead of through a product owner. Or even that tickets on a board are not a useful way to work at the moment. Things have to stay Scrum.

Re: Scrum is a cancer

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

[flagged]

> Scrum _is_ a bit like communism. Each time it fails people claim it's wasn't the real thing.

The difference is when people do communism, they actually follow the recipe (and failing), i.e. central planning, one-party state, state ownership, etc.

But when you read about people complaining about Scrum, it doesn't look like what the Scrum training taught nor the Scrum guide.

(This reminds me of a time when a manager pulled all the teams into a room, then pulled out all the Scrum terminologies and say "now we're going to have a meeting to decide what we want them to mean".)

Re: Scrum is a cancer

#445
post #374

Earlier quoted context omitted.

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

> What are you doing that it could ever take _half_ of total work time and how will you convince management that you aren't completely fucking up scrum?

Oh, that's very easy. So much so, I wonder exactly how you managed to perform everything required for a planning or review in the time you give. Business meetings can take more than expected in the best of cases, and the various dysfunctions inherent in scrum only add to that.

Here's a fairly obvious example - scrum encourages you to have a lot of management. At minimum a team needs a product owner, a team lead and a scrum master (and if you merge those positions you aren't "doing scrum properly"). Because there are so many managers, each is under pressure to prove they add value. How do they prove that? By providing valuable input in the various ceremonies scrum requires. Hours of it.

And sometimes they add so much value it can't be contained in the normal flow of scrum meetings (or rather, the meetings can't be contained in the course of a work day), so more meetings have to be created.

Re: Scrum is a cancer

#446
post #378

Earlier quoted context omitted.

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.

Saw it after getting hooked on Silicon Valley and I’m glad I did. Both come from Mike Judge just as Idiocracy does which is simply brilliant. Had I known that he’s also behind Beavis & Butthead, I would have given it all a hard pass. Now I’m thinking, maybe I just misunderstood Beavis & Butthead.

Re: Scrum is a cancer

#447

Earlier quoted context omitted.

His point is not exactly invalid though? If you go into something with the intention of 'this sucks' and then do not even want to make it work would it not reason that it probably will fail? Scrum usually fails because people become enamored with the process instead of thinking about what that process is for. Layering on more and more of it because something is not working. Until you are busy with 40% of your time ju…

I can't tell if you are saying Scrum socks when people hate it or when people are enamored with it. I guess it will work if everybody is casually indifferent?

Scrum sucks when people ignore why they are using it and decide to use it just because everyone else is. indifference is usually the root cause of broken scrum. No one speaking up and saying 'lets fix this'. Things piled on for no real reason but not thrown out when they are shown to just be in the way. Throw in a 'bad actor' and yeah it can really suck but then the whole job will anyway no matter what your process. No one really wants to work with a grumpy person. That is not the fault of scrum that is a organization/people problem.

Re: Scrum is a cancer

#448

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.

Office space is actually accurate once you replace TPS reports with Status reports/JIRA tickets/Performance reports/Incident reports etc. The amount of dancing required for the sake of management in this industry is just insane.

As a long time PM (of all sorts of P)...

If you don't want to have to talk to customers, which only one developer who I've ever worked with has actually wanted to do, you need a way to equip someone else to do so.

Same thing if you want to keep your investors happy, your counterparts in other departments informed of when they need to have the hardware to pair up with your software ready, etc.

There's definitely such a thing as too much overhead, but developers who just do the things they are interested in without considering that they are part of a larger business are the other side of the coin that you're describing.

Re: Scrum is a cancer

#449
post #420

Earlier quoted context omitted.

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

There may be a mythical "scrum" out there somewhere, but I and no one I've ever known has seen it. As much as I love a No True Scotsman fallacy, if this is the only thing people have ever seen and have ever attached the label "scrum" to... Then that is what scrum is.

Well you don't know me but I am not a scrum master and I was on a team that had a great experience with it and are all still friends years after we all went to other jobs. It was the great experience of my life.

I know how it worked and why every team I've been on since has not been able to make it work and it all boils down to: 1) internal sabotage - an influential developer does everything they can to shit on it. 2) Management interference - developers could not change the things we needed to change to make it fit our circumstances.

Re: Scrum is a cancer

#450

Earlier quoted context omitted.

> It doesn't particularly matter whether people are disappearing because of shamble-men or because of bears and wolves, if people are regularly disappearing in the woods then you'd do well to steer clear of them. “Steer clear of things called Scrum” is a very limited guide to how to develop software, actually figuring out what the methodological pitfalls are and addressing them is something that is, I would submit, w…

I'm not suggesting that "don't call it Scrum" be the final word in software development methodology. I am suggesting that calling it Scrum will increase your risk of failure, and you'll likely be better off choosing a completely different methodology that has more consistency in implementation and a higher success rate. By all means let's dig into what specific details of the implemented methodologies work well and w…

> By all means let's dig into what specific details of the implemented methodologies work well and which don't! But taking the output of that process and calling it "Real Scrum™" will just lead to further confusion.

I’m not saying “Real Scrum™” should be the name of the output. I’m saying that diagnosing the problem is obscured by not distinguishing between “what is in the Scrum Guide” and “what someone is doing and calling Scrum”, especially as the latter can be a diversity of mutually incompatible approaches.

Post reply on HN