Scrum is a cancer
twitter.com
Scrum is a cancer
1–10 of 486 posts
Re: Scrum is a cancer
#2[dead]
Re: Scrum is a cancer
#3My company bought into the SAFe bullsh*t and it’s awful.
Re: Scrum is a cancer
#4My company bought into the SAFe bullsh*t and it’s awful.
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.
Re: Scrum is a cancer
#5I know for a fact engineers on my team that called me crazy for thinking scrum is snake oil sold to management will upvote this.
Re: Scrum is a cancer
#6Typical 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 generalized all developers as a bunch of fat neckbearded social cripples reeking of BO? Same thing here.
I ought to bookmark this post in case anyone thinks that people on HN don't try to farm karma Reddit-style. What a crap bunch of outrage bait.
Re: Scrum is a cancer
#7Typical 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.
Re: Scrum is a cancer
#8My company bought into the SAFe bullsh*t and it’s awful.
Why would you hate spending 1 month out of 4 for “planning” and then 40% of the time in the remaining 3 months also for “planning” resulting in a massive destruction of productivity all so you can now claim that “yeah, you delivered a fraction of what the company was delivering pre SAFE, but at least we planned on delivering a fraction of what we delivered Pre-SAFE.”
Re: Scrum is a cancer
#9My company bought into the SAFe bullsh*t and it’s awful.
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 year from now you should have reduced 50% of the ceremonies you started with.
The goal should be expose people the universe of options and ideas available, and then once exposed, require them to pick and choose between all these options to tailor their own customized solution which works best with the people on their team and the working styles and the kind of work they’re doing.
Re: Scrum is a cancer
#10My company bought into the SAFe bullsh*t and it’s awful.
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.
It is a good question but the answer may be unsatisfactory: it depends. I think that the popularity of scrum is due to its catch-all nature and the way it sounds reasonable when you explain it to someone, especially a non-developer.
Here is an answer that (I believe) works well: Hire a team lead that is willing to shield a small dev team (less than about 7 people) from the politics above. The devs still talk to users and other people in the company but they do not necessarily have to be accountable to them. The team lead understands the company’s budget cycles, has a vision for the product being developed and, importantly, has the time to sit down with each developer on the team to look at what they are making. Not a code review but a regular show-and-tell kind of arrangement. The fine line in this approach is to make sure it doesn’t degrade to micromanagement and ego poking.