this post was submitted on 22 Jul 2023
57 points (78.2% liked)

Unpopular Opinion

6315 readers
3 users here now

Welcome to the Unpopular Opinion community!


How voting works:

Vote the opposite of the norm.


If you agree that the opinion is unpopular give it an arrow up. If it's something that's widely accepted, give it an arrow down.



Guidelines:

Tag your post, if possible (not required)


  • If your post is a "General" unpopular opinion, start the subject with [GENERAL].
  • If it is a Lemmy-specific unpopular opinion, start it with [LEMMY].


Rules:

1. NO POLITICS


Politics is everywhere. Let's make this about [general] and [lemmy] - specific topics, and keep politics out of it.


2. Be civil.


Disagreements happen, but that doesn’t provide the right to personally attack others. No racism/sexism/bigotry. Please also refrain from gatekeeping others' opinions.


3. No bots, spam or self-promotion.


Only approved bots, which follow the guidelines for bots set by the instance, are allowed.


4. Shitposts and memes are allowed but...


Only until they prove to be a problem. They can and will be removed at moderator discretion.


5. No trolling.


This shouldn't need an explanation. If your post or comment is made just to get a rise with no real value, it will be removed. You do this too often, you will get a vacation to touch grass, away from this community for 1 or more days. Repeat offenses will result in a perma-ban.



Instance-wide rules always apply. https://legal.lemmy.world/tos/

founded 1 year ago
MODERATORS
 

All it does is let leadership not define what they actually want, and make changes on the fly, which leads to longer dev times and worse code. Fuck agile, bring back waterfall.

top 34 comments
sorted by: hot top controversial new old
[–] [email protected] 37 points 1 year ago (2 children)

Agile is better if done properly, because it recognizes the fact that things change ovar time.

The problem is that business never does things properly. Setting artificial deadlines, or the opposite and being completely unguided

At it's core good agile is just shorter waterfall.

Also I would suggest code that can not handle requirement adjustments without becoming bad was never good to begin with. After all even waterfall finds things have changed at the end of development and the need for a new waterfall design afterwards

[–] [email protected] 12 points 1 year ago* (last edited 1 year ago)

At it's core good agile is just shorter waterfall.

This right here. You can still define scope and requirements and not deviate from that (too much) by delivering chunks of functionality iteratively so that you know you're on track.

[–] [email protected] 26 points 1 year ago (1 children)

The problem is that it's a lot easier to implement agile poorly, than it is to implement it in a way that works.

You've essentially described what agile shouldn't be. The fact it's called agile, means people assume it just means you can change things whenever you want because that's being "agile". That isn't what agile methodology is meant to be. If that's what you're experiencing, then it's being done wrong. And it's frustrating because this is extremely common.

Waterfall can be just as bad. I've worked on plenty of waterfall projects only to spend months of my time on things that never see the light of day. Things change, and waterfall can rarely deal with change mid-project without starting over. It's completely dependent on the context of the work.

[–] [email protected] 2 points 1 year ago (1 children)

Agile is like communism. Nice in theory. Never works in actual practice.

If praxis can never even come close to theory, and indeed if praxis is almost always worse than the alternative it was replacing, your system is untenable.

Agile is untenable.

[–] [email protected] 2 points 1 year ago (1 children)

I disagree. I'm currently working in agile and it's the best team I've worked in/with. It can easily go wrong, but it can also work really effectively. Implementing agile in an "ok" way, is still better than waterfall in most instances. Of course it depends on the business context.

Take all of OPs complaints for example. Sure, they can be an issue if agile is implemented poorly (or not at all in OPs case), but all of them are inherent issues with waterfall. Developing something only to find out days before launch the business has something else in mind. There would be much less chance of that happening in an agile environment over something like waterfall.

There's a big problem with people saying they work in agile, when they're really not. Like in OPs instance. And that leads to the negative sentiment about agile never working. I get it, I've been there and had to work in agile teams that weren't really agile. That doesn't mean it can never work.

[–] [email protected] 1 points 1 year ago (1 children)

Take all of 's complaints for example. Sure, they can be an issue if is implemented poorly (or not at all in 's case), but all of them are inherent issues with .

If you're making constant excuses bout "implemented poorly" and the majority (I'd argue all) instances of your approach are "implemented poorly" and thus fail, then the issue is your approach.

[–] [email protected] 1 points 1 year ago (1 children)

So if all approaches are poor, then anarchy? I think you need to move on from the communism comparison, and the idea that unless something is perfect it's not worth doing.

Believe it or not, there are people working in successful agile teams right now. Just because you haven't, that doesn't mean it isn't tenable.

[–] [email protected] 0 points 1 year ago (1 children)

Please point where I said we should just do what we want (anarchy). (Hint: this is not possible.)

Let me quote what I actually said , K?

If you’re making constant excuses about “implemented poorly” and the majority of (I’d argue all) instances of your approach are “implemented poorly” and thus fail, then the issue is your approach.

(I corrected a couple of minor typos.)

Now let me take this apart.

If you're ...

The conditional is very important here.

... making constant excuses ...

So is the word "constant".

... about “implemented poorly” ...

This is the crux of the argument. If your argument in support of a system is that its failures are all "implemented poorly"...

... and the majority of (I’d argue all) instances of your approach are “implemented poorly” ...

... and if most of the attempts to use your approach are mysteriously "implemented poorly" ...

and thus fail, then the issue is your approach.

... then the problem is your approach, not the implementation of it. Good systems fail safe. Good systems do not require perfection in implementation to see benefits. Good systems, if imperfectly applied, should at the very least not be worse than the alternatives.

In most cases (and again I'd actually argue all, but that's a personal bias) of "agile" the system fails and turns into a clusterfuck worse than the approaches it tries to replace. It does not fail safe. And whenever this is pointed out, invariably someone comes out of the scrum to point accusing fingers at where it was "implemented poorly".

But you know what? There are engineering processes that even when people fail at elements of them you still see actual improvement in outcomes from trying to apply them. I don't see this in agile. Ever. It, like communism, requires people to be perfect little robots doing every piece of the system perfectly to achieve the purported grand benefits.

And I ain't buyin'.


Incidentally, would you mind sharing with me what you think 'waterfall' is? I have a suspicion what picture you're going to share and if you do, I'm afraid I will laugh at you.

[–] [email protected] 1 points 1 year ago

Agile isn't meant to replace anything. You need to use the right method for your context. No one said the purpose of agile is to replace all other methods.

Agile doesn't have to be implemented perfectly to work. You seem to be holding agile to some higher standard than anything else.

You have to get over the communism comparisons. They aren't relevant.

Just because you haven't worked in an agile environment you enjoyed, that doesn't mean it can't work. It can and does work. Just like any other method. And it can and does fail. Just like any other method.

OP didn't work in agile. They were told that they were working in agile but it was just an excuse for the business to not have requirements and continually change their mind. Every one of the issues they raised could have happened in any other methodology. It's poor management.

[–] [email protected] 24 points 1 year ago (2 children)

You haven't developed waterfall software have you.

[–] [email protected] 13 points 1 year ago (1 children)

Yeah I hated the waterfall methodology as a project manager. I can only imagine what it's like as a dev.

[–] [email protected] 14 points 1 year ago

Brutal. Most of the time it's like watching a car crash in slow motion... Over and over again.

[–] [email protected] 19 points 1 year ago* (last edited 1 year ago)

Agile, SAFe, V model, waterfall. I've done a shit ton of different models of software development in my twenty years and each one leads to the same damn scope creep if you don't have leaders that push back against the customer and their expectations.

Every methodology sucks until you've moved to the new one but I will say that waterfall belongs in a special level of hell and at least with the agile framework I as a tech lead can push back more effectively against the acceptance of increases scope and push things to the right.

[–] [email protected] 7 points 1 year ago

In my experience, it's better when people are accountable for defined stories without scope creep in the name of being agile. Or having entirely blank story descriptions "that will be filled in later" but make sure you add a story point!

[–] [email protected] 5 points 1 year ago

Drop the dogma, know what you want, have a plan before each step starts, and work incrementally. Agile doesn’t account for the reality of programming for corporations, although I think it can still be useful in consulting contexts…. Maybe

[–] [email protected] 4 points 1 year ago

Delivering small chunks of functionality is much better than waterfall in a major project. Big waterfall projects can spend so long in analysis and design that they get cancelled before they really get started.

The real issue with “Agile” is that short term task level estimates are pointless and inaccurate. You can’t estimate really until you understand the task, know who is doing it, their area of expertise and skill level, and how focused they will be without being pulled into other projects, questions etc.

Delivering regularly without micromanagement, removing scope to shorten deliveries, and providing very high level project estimates make more sense.

[–] [email protected] 2 points 1 year ago

These methods are merely ways for management to hide their incompetence and/or micromanage the people who work.

[–] [email protected] 1 points 1 year ago

No fucking argument here.

[–] [email protected] 1 points 1 year ago

In my experience, Scrum (which is an implementation of Agile), if done properly, can work faster than the waterfall. Especially in bigger teams where you would have people on standby to wait for other things to be done. This lets the bickering Architecture team to bicker while we, the developers, implement the things that have been settled on. It's nasty when the Architecture team decides to change things already settled on because they are very detached from the rest of the development challenges, but at least we know who to put pressure on and why

[–] [email protected] 1 points 1 year ago

what if I am both the developer and the project leader?

load more comments
view more: next ›