Comment by alkonaut | Hacker News Reader

Comment by alkonaut | Hacker News Reader

Agile (Scrum rather, but this article appears to be about implementing agile through scrum) trades one set of problems of software development, for another set of problems. That needs to be understood I think. Some times when agile is treated like dogma and religion this somehow gets lost. It's a tradeoff. It's popular because this new set of problems is deemed to be a better set of problems to have than almost all other sets of problems you'll end up with.

Switch to waterfall, and you'll have problems with that. Try whatever process, and there will be a set of problems that comes from it. Scrum is a flawed process, but there are many flawed processes. A lot of scrum-haters (understandably) argue against scrum, but what I'm missing is the presentation of the alternatives. We are going to be miserable and stuck doing scrum for the coming century unless we can formulate and demonstrate good alternatives. And if we don't want the processes to be upper-management centric, we better formulate the alternative as developers.

The places where I have seen scrum function well (teams delivering features without burnout, without losing grip of the big picture because of constant micro-development etc.) are in teams that are high performing and highly functioning. But of course those teams would have been well functioning and productive with any process.

The allure of scrum (in my opinion) is that it makes teams that would likely have delivered nothing, deliver something, or at least not waste time building the wrong thing. It's a way for management to increase the transparency and lower the risk of software development with poor software developers and/or bad teams. And that, to be honest, isn't something to be scoffed at. Throwing a poor process onto a bad team means you'll get miserable developers and risk having nothing produced. Agile means miserable developers and hopefully some transparency too. Not great, not terrible.

> It's a way for management to increase the transparency and lower the risk of software development with poor software developers and/or bad teams.

So, it's kind of an "observability tool for teams' production process management"? (to reframe it in a more contemporary fashion)

Edit: I guess we're headed to having pulse, blood pressure, VOmax, weight, daily exercise and so... metrics also displayed along mood and burndown charts. :p

> So, it's kind of an "observability tool for teams' production process management"?

Absolutely, I think thats literally on the label and not in the fine print of the Scrum tin.

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

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.

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.

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

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

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.

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.

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

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.

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.

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

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

Reply on news.ycombinator.com