3 ms·

> Agile means miserable developers and hopefully some transparency too. Why are developers who work in an agile environment miserable? If you take scrum, doesn

> Agile means miserable developers and hopefully some transparency too. 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?

BlargMcLarg 4y ago
Retrospectives open the ability to provide feedback. That doesn't mean anything will happen with that feedback. That's before considering social theory and tact, where it becomes obvious being rebellious is generally a bad move socially unless you're already willing to leave, are in a position of power over others or the crowd is willing to take your side. Meanwhile these "agile" environments tend to push maximum social participation from developers at the benefit of management. "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.
Juliate 4y ago
You may only improve what you can influence, within your agility bubble: does it stop at your team, or does it embrace the whole company structure.
alkonaut 4y ago
> Why are developers who work in an agile environment miserable? 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.
- jdlshore 4y ago
  "You aren't doing it right" is a valid argument when "it" is well defined. No True Scotsman is a fallacy of ambiguity—it occurs when "Scotsman" isn't well defined, allowing somebody to continually move the goalposts in response to an argument. 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.
  - crimony 4y ago
    I can't help being amused by this comment, which seems to to be arguing: "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.
    - jdlshore 4y ago
      Sure, I can see the irony. On the other hand, your interpretation of my argument is absolutely correct. I'm saying that people in this thread have gotten two things wrong: 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.
bryanrasmussen 4y ago
>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? 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.
p0nce 4y ago
Because your average software company has power captured by management (instead of designers or producers), workers can't speak to users as they wish, making it a blind sprint into nothing, and the added value of making successful software is going to be captured by the top of the hierarchy, who is convinced to have the best ideas.
spaetzleesser 4y ago
From my experience feedback from retrospectives rarely gets acted on. You can make changes that are isolated to your team but you quickly reach a point where other functions need to change their process. To make these changes you need support from senior management but I have never seen anything happen besides words.
zippergz 4y ago
It's another meeting on my calendar potentially interrupting whatever deep focus I was in. Alongside standup, sprint planning, demo, sprint review, backlog grooming, and whatever other non-agile meetings there are. 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).
- azangru 4y ago
  > 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. 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.

BlargMcLarg 4y ago

Retrospectives open the ability to provide feedback. That doesn't mean anything will happen with that feedback. That's before considering social theory and tact, where it becomes obvious being rebellious is generally a bad move socially unless you're already willing to leave, are in a position of power over others or the crowd is willing to take your side. Meanwhile these "agile" environments tend to push maximum social participation from developers at the benefit of management. "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.

Juliate 4y ago

You may only improve what you can influence, within your agility bubble: does it stop at your team, or does it embrace the whole company structure.

alkonaut 4y ago

> Why are developers who work in an agile environment miserable? 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.

jdlshore 4y ago
"You aren't doing it right" is a valid argument when "it" is well defined. No True Scotsman is a fallacy of ambiguity—it occurs when "Scotsman" isn't well defined, allowing somebody to continually move the goalposts in response to an argument. 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.
- crimony 4y ago
  I can't help being amused by this comment, which seems to to be arguing: "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.
  - jdlshore 4y ago
    Sure, I can see the irony. On the other hand, your interpretation of my argument is absolutely correct. I'm saying that people in this thread have gotten two things wrong: 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.

bryanrasmussen 4y ago

>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? 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.

p0nce 4y ago

Because your average software company has power captured by management (instead of designers or producers), workers can't speak to users as they wish, making it a blind sprint into nothing, and the added value of making successful software is going to be captured by the top of the hierarchy, who is convinced to have the best ideas.

spaetzleesser 4y ago

From my experience feedback from retrospectives rarely gets acted on. You can make changes that are isolated to your team but you quickly reach a point where other functions need to change their process. To make these changes you need support from senior management but I have never seen anything happen besides words.

zippergz 4y ago

It's another meeting on my calendar potentially interrupting whatever deep focus I was in. Alongside standup, sprint planning, demo, sprint review, backlog grooming, and whatever other non-agile meetings there are. 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).

azangru 4y ago
> 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. 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.