Live data from Hacker News

Scrum is a cancer

twitter.com

31–40 of 486 posts

Re: Scrum is a cancer

#31

Typical immature bullshit where someone describes their own company's screwed-up incompetent so-called "Scrum" and "Agile" implementation, and then claims that that's universalizable amongst all companies everywhere. Just because a so-called "Scrum Master" not worth the title is forcing you to do BS things that inhibit your flow does not mean it's emblematic of the species. I mean, how would you feel if someone gener…

This is a No True Scotsman argument. The guy enumerated a list of ways scrum failed in his experience; it's always interesting to hear honestly about failure modes from people who have actually used something a lot in their work.

It's interesting to hear about failure modes, and anyone whose job it is to teach stuff like this is interested in hearing about failure modes. It's the taking of one person's experience and extending it to encompass everything that's wrong.

Obviously the people charged with implementing this in OP's company are doing it wrong. That doesn't mean it's OK to insinuate that everyone who ever tries to implement Scrum or Agile is doing it wrong. For every clueless toxic manager who doesn't understand how to use Agile correctly, there's an egotistical or lazy dev who also wants to throw what the Brits would call a spanner in the works for purely personal reasons.

But to call it a No True Scotsman argument is a lazy rebuttal which won't engage with the argument. There are plenty of shitty Agile practitioners, and no one is trying to dispute this.

Re: Scrum is a cancer

#32

From Peopleware: “In the 1985 Jeffery-Lawrence study [from the University of New South Wales]…they investigated the productivity of 24 projects for which no estimates were prepared at all. These projects far outperformed all the others…Projects on which the boss applied no schedule pressure whatsoever (‘Just wake me up when you’re done.’) had the highest productivity of all.” I read 20+ books on management and leader…

Our team is the only one not doing “scrum” or estimates or shit. Our team is the only one far ahead because we don’t waste our lead engineers’ time and allow them to move at their own pace (that means very fast). I just have 15 minute dailies with the other senior and the manager to stay in sync.

Re: Scrum is a cancer

#33
post #22
post #11

How do I avoid this in my career?

Call it out as BS when it comes up in discussions. Spread the word. Stop going along to get along.

In a large organization, this will change nothing. All you can do is be in a trusted position with upper management, and spend your political capital to prevent it. Even then, it may not work if some exec has implementing it as a goal to help their prestige/career.

Re: Scrum is a cancer

#34
Clever management technique in a shop full of blunt knives will only get you so far.

With my team, we’ve focussed on developing talent just as much as we have on getting the work done. By improving skills through senior-to-junior coaching and code review we’ve built a much more cohesive team that’s better at what they do and can complete tasks which they couldn’t do before. Dexterity and fluency with code was more important to us than organisational skills.

Perhaps I’m missing the point and Scrum is only for people at the top of their game? It didn’t feel that way the few times I’ve seen it — to be a little bitchy, it appeared to be quite the opposite.

Re: Scrum is a cancer

#35
post #17

Earlier quoted context omitted.

Typical Scrum apologist who describes how someone else must have screwed up Scrum or Agile. They then claim that pure "Scrum" or "Agile" has never been implemented anywhere. If only people weren't so ignorant, we could give pure Scrum a try and solve all the world's problems.

> They then claim that pure "Scrum" or "Agile" has never been implemented anywhere. They are right, however the conclusion that should be drawn from this is that the most likely outcome of your organisations implementation of agile will be equally as poor, and that it should prolly be skipped.

Typical argument from an engineer arguing from math and not understanding that math does not describe human beings and their social relationships.

Re: Scrum is a cancer

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

I had a team with a shadow backlog. Fun times

Re: Scrum is a cancer

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

I work on a very small scale nowadays, but what I have found to be helpful is "weekend fun" tickets. Nice to have things that I wouldn't do otherwise but are fun when I don't have the energy for other stuff / when I consciously try to reward myself.

Re: Scrum is a cancer

#38

If you're in a situation where someone is suggesting applying an off-the-shelf process like Scrum or SAFe, you've already lost. > 3. We prohibited laptops in meetings. We had to stand. We passed a ball around to keep everyone paying attention. This continues to be one of the most aggravating parts of capital A Agile software development. Forcing people to be uncomfortable to make them talk less is something a child w…

If you’re going to have lots of unnecessary meetings, it’s important to keep them short or no one will have time to do work.

Re: Scrum is a cancer

#39

Typical immature bullshit where someone describes their own company's screwed-up incompetent so-called "Scrum" and "Agile" implementation, and then claims that that's universalizable amongst all companies everywhere. Just because a so-called "Scrum Master" not worth the title is forcing you to do BS things that inhibit your flow does not mean it's emblematic of the species. I mean, how would you feel if someone gener…

Typical Scrum apologist who describes how someone else must have screwed up Scrum or Agile. They then claim that pure "Scrum" or "Agile" has never been implemented anywhere. If only people weren't so ignorant, we could give pure Scrum a try and solve all the world's problems.

This is like complaining that because the shittiest sports team you follow doesn't win that playing that sport well is ipso facto impossible.

Re: Scrum is a cancer

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

Personally, I think SAFE or Agile/Scrum are good starting points. The key part, however, is teams, departments, and companies, then modifying their actual working by eliminating ceremony and process. The way I think Agile/Scrum/SAFE should work is that you expose all the teams to all the ceremonies, and all the different alternatives to each of the ceremonies to start with, but you also mandate thst 6 months to a yea…

I heard an interesting perspective for startups - Kanban/Scrum is useful sometimes before launch, and not using scrum after is beneficial.

Mostly because launching changes so much.

Part of me does feel sometimes that ceremonies are for making sure the development practice is highly inclusive, including for new and less skilled developers still learning their ways. Another part of me thinks about how this also helps more people to be able to generally help with more of the codebase.

I think writing code for your future self or someone else, in a way you'd like to receive is critical to think about. This can include doing things the simpler way even if it's more verbose and more understandable. This isn't always possible, but more often than not, avoidable complexity also can encourage the engagement of a lot of ceremony around it. "Could this have been simpler?" is one useful question for code reviews.

Post reply on HN