If you want something short and easy, try Elder Race. It’s a novella, but very well done. The good thing about him is that he’s so prolific, there’s a lot to choose from.

They’re real! Looking forward to hopefully getting mine by the end of the year.

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.

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.

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.

That’s the biggest problem with waterfall to be honest. You can sit there and point at requirements, but requirements can be interpreted differently. And that’s a bigger issue with waterfall because you’re handed a list of requirements with little context on what the purpose is of what you’re doing because you weren’t in any of the conversations earlier on in the process.

Agile doesn’t mean you don’t have requirements. What happened really sucks. But you aren’t working in agile. You’re just being screwed.

That totally sucks. But has nothing to do with agile. That could have happened with waterfall because you would have sat there and developed things in isolation only to find out at the end it wasn’t what was expected.

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.

But sometimes you might just want to go back to something you upvoted, without needing to save every post or comment just in case.