There are several ways in which it's bad. Forcing all the work to fit into sprints, for instance.

What if the natural way to divide the work results in some chunks that probably don't fit? Normally you'd just do them and it's be fine, but "we're doing Scrum" so now they have to be divided further and the parts have to be developed separately, even if that makes no sense.

Also Scrum assumes things -- that the product owner is very competent, that dev teams are self managing, that the business is interested in updates in the same frequency as the sprint -- that aren't necessarily true.

And everything that goes wrong is blamed on Scrum not being done exactly to the letter. So nothing else is fixed and everybody is more and more focused on doing Scrum ceremonies precisely right even if that was never their intention.

>There are several ways in which it's bad. Forcing all the work to fit into sprints, for instance.

That's misusing it. The sprints are just forcing regular meetings to assess progress and make changes if necessary. There's no reason to absolutely force everything to get done in 2 weeks. If something doesn't get finished in a sprint, discuss what happened in the biweekly meeting and if any changes need to be made, and then move it to the next sprint.

I believe the SCRUM rejection comes from the direct experience of working in a team that uses it, and eventually realizing that all of the meetings and concepts because an end in itself. SCRUM usually degrades to more discussions about story points than about what is being built.

I think this is just an example of the fact that any tool can be misused or used poorly. I used scrum at my last employer, and it worked quite well. But we didn't use it stupidly; it was just a tool to keep track of what we were working on, and plan what we were going to work on next, that's all.

Sure, we had some discussions about story points, but they were quick. When we had to assign story points to a task, we'd all use story point playing cards (they have the typical Fibonacci sequence story points printed on them: 1, 2, 3, 5, 8, 13, 20) and turn them over at the same time to basically vote on the points. If there were any large disagreements (one person voting 1 while everyone else votes 8 for instance), we'd stop and discuss why that person thought it would be so much more or less effort. Usually, 30 seconds of discussion would clear up the disagreement and we'd move on to the next task. The whole meeting would last less than 1 hour, and was held every 2 weeks. And I think it had a secondary benefit: it got us all in the room together to just talk to each other as team, instead of just sitting in front of our computers and not talking to anyone, which was our usual activity. Social interaction is good for people.

If someone votes 1 while the others votes 8, he’s either too optimistic or an expert on that subject. The points themselves don’t matter, because things are either hard or easy, and that usually depends on the person doing it. No committee can decide that. And they will either get done or cancelled any way. The only things that really matter is their current priority. And that’s the business decision (influenced by several factors, including the advices of the devs). The points assignments are thus useless and you’re spending 1 hour every two weeks on it. But if it makes everyone happy…

And as for talking as a team, we can just do it without any other excuse than discussing the project and the methodologies.

The points assignment wasn't useless; it was just for tracking relative difficulty. Some tasks were trivial, only taking a couple of hours, so they got a "1", while other tasks were projected to take 2 weeks, so those got an "13". The idea was to pick a bunch of tasks that were basically do-able within the 2-week sprint, and ignore the rest, so while 1 dev might take on a 13-point task and nothing else, another dev might take a bunch of 1s and 5s. And yes, the priority had to be factored in too, which was influenced by both customer requests and dev input (i.e., "this is super easy and I can have it done today" or "this is difficult and will take a month").

>And as for talking as a team, we can just do it without any other excuse than discussing the project and the methodologies.

You can, but no one actually does it in practice. Individual team members might chat together from time to time, but putting everyone in one room together forces them to interact with all their other team members and talk about real work-related stuff, instead of just hanging out with their one buddy and talking about something irrelevant.

scrum is much more than “a shared to do list”. organizations that self-identify as adopting “scrum” are the most dysfunctional i have ever worked at

> But when it comes to a shared to-do list across a team

That would be Kanban.

> then that is apparently the worst thing to ever happen to a project.

Naah: The worst thing to happen to a project is all the rituals, ceremonies, processes, meetings, estimations, deadlines... That it also contains a shared to-do list isn't enough of a saving grace, seeing as how you could have the shared list without all the other bumf.

if it were just a shared to-do list, that would literally be kanban

It's a shared to-do list with a biweekly meeting on the list, and a daily update on if things are on track or someone needs help.

It’s a shared to-do list with a biweekly meeting to review and cleanup the to-do list, a biweekly meeting to select items to be worked on in the next biweekly period, and a biweekly meeting to discuss how the last biweekly period went. And a daily update meeting.

Exactly this. When I used it, that's exactly how it was, and honestly it was great compared to the utterly chaotic and disorganized method of organizing work I've seen in other workplaces.

It seems like all the people who absolutely hate it worked in dysfunctional places that completely misused the tool, or treated it like some kind of religion.

> how adamant the typical HN'er is about having good commit messages, and follow a strict merging paradigm, such as peer reviewed pull requests

That’s communication, and sometimes a protocol helps nicely in getting the relevant information out of the medium. Especially when the communication is async as everyone knows roundtrips is bad.

> with lot's of room for discussing minute details of rebasing versus merging with or without squashing

That’s geeky time out of work. When doing it, we know that we’re not working.

> a shared to-do list across a team

The shared list is not the issue. It’s what happens to the items inside it. Scrum make us work more on the item organization than what it’s worth. Then they get arranged into something that doesn’t really matter (sprint), and then we are judged on that. While we just want to get things done.

I dont remember anybody ever objecting to a shared to do list.