Agile is shit and leads to worse outcomes.
Agile is shit and leads to worse outcomes.
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.
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
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.
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.
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.
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.
You haven't developed waterfall software have you.
Yeah I hated the waterfall methodology as a project manager. I can only imagine what it's like as a dev.
Brutal. Most of the time it's like watching a car crash in slow motion... Over and over again.
No I haven't, but its better than finding out that you were supposed to make a mobile app on go-live day, instead of a website. Same basic functionality, but completely different front end.
That's... Not agiles fault... This is a systematic failure of project management.
Besides, if you were doing agile and the business you were working with participated you would have ended up with a version in their hands they should have said was the wrong thing 2/3rds of your development time ago...
That sounds like a problem with project scope, not with agile or waterfall.
The issue is that people read “agile” and assume that means the entire project scope can be quickly changed. You still need a proper scope, even when using agile.
This is literally the critique on waterfall (project goes and makes what they believe the customer want, comes back months or years later, turns out they made the wrong thing and wasted so much time) and what agile aims to solve (have regular check in moments to see if the project is still on the right track and adjust when needed).
In my experience it helps to define a roadmap and stick with that direction. Figure out the details when you start working on a roadmap item. Adjust the roadmap every 6 months or so, only deviate earlier when the situation calls for it. This requires sometimes being able to say 'no' to your customer and them accepting it.
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.
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!
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
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.
These methods are merely ways for management to hide their incompetence and/or micromanage the people who work.
No fucking argument here.
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