Why are developers who work in an agile environment miserable? If you take scrum, doesn't it include retrospectives, with the express purpose of allowing developers to reflect on their misery and to gradually improve their condition?
"No true Scrum/agile" aside, this is the reality of many. The fundamental problem still lays in the power difference between ICs and upper management. Even if it is "inefficient", so are many things done by modern corporates. Showing something can be done more efficiently isn't a guarantee the company will become leaner.
It's an hour plus of sitting there mostly listening to other people complain about stuff, which bums me out even if I was otherwise generally happy.
It is a ceremony without actual purpose because usually the deeper things that people bring up are not within that team's power to control.
It gives leadership an excuse for not fixing things or listening because retro is supposed to be the outlet for gripes about the process (despite everyone knowing that major changes never happen coming out of retro).
> It is a ceremony without actual purpose because usually the deeper things that people bring up are not within that team's power to control.
From what you said, it sounds like there are already several things that are making you miserable and that could be addressed in a retrospective.
First, remind each other about the intended purpose of a retrospective, and compare this with how you conduct your retrospectives. Read up on what retrospectives are intended to be. Notice any discrepancies with your retrospectives.
Second, talk about what it would take to make retrospectives a useful event. Maybe, agree that you don't discuss things that are out of your control. Or maybe have a retrospective specifically addressing the things that are outside your immediate control, and ask your scrum master to figure out ways to bring at least some of them under your control. After all, that is scrum master's role, not the micromanagement of the team.
Third, if your retrospectives are an irredeemable waste of time, and there is no way to improve them, agree within your team that you will stop having them. This is probably a last resort — but it's better than to waste your time.
first thing to improve, get rid of retrospectives
second thing to improve, if having retrospectives have them in such a way that nobody feels like they have to come up with some things you can improve, keep doing etc. etc. every two-three weeks.
Yes. And yet that often doesn't happen. And that's where one might argue "well then you aren't doing it right", but that's precisely the No True Scotsman argument.
I see teams be miserable, have all the power to do something about it, including buy-in from management, yet they remain miserable. A key feature of any alternative methodology and organization should contain this: It's the role of management to ensure teams aren't miserable. Merely giving teams the tools to do so doesn't make it happen.
In the case of Agile, Scrum, and retrospectives, they all have published definitions, so No True Scotsman doesn't apply.
Are you valuing processes and tools over individuals and interactions? You aren't doing Agile right. (Agile Manifesto)
Does your team not consist of "one Scrum Master, one Product Owner, and Developers [with] no sub-teams or hierarchies [who] internally decide who does what, when, and how?" You aren't doing Scrum right. (Scrum Guide)
Does your retrospective not include "Decide what to do?" You aren't doing retrospectives right. (Agile Retrospectives book.)
In fairness hardly anybody does these things right, so it's tempting to lob No True Scotsman criticisms. But that's just as fallacious. A more accurate criticism might be to say that Agile & co. are too hard to do right, or to say that they require a business environment that doesn't exist in most companies.
"This isn't a One-True-Scotsman fallacy, a true One-True-Scotsman fallacy would be <insert narrower definition>, your claim about this fallacy is fallacious"
I'm pretty sure Agile, Scrum and Retrospectives have multiple published definitions, both broad and narrow.
1) They don't understand Agile, Scrum, or retrospectives, each of which have authoritative definitions (which can be found at agilemanifesto.org, scrum.org, and in the Agile Retrospectives book).¹
2) Furthermore, they don't understand the "No True Scotsman" fallacy.
Correcting a misunderstanding is not "No True Scotsman." If somebody called a car a "horse," and you said, "that's not a horse—a horse has hooves, not wheels," would that be No True Scotsman?
¹You could argue that those definitions are overly broad, or fuzzy, or many other things. But that's not what people in this thread are doing. They're saying horses have wheels, then saying it means horses can't jump.