Call me cynical, but I am always surprised when people sincerely appeal to "agile/scrum values" of team autonomy or whatever to contest management diktats because, like... isn't it totally predictable that that part will be ignored whenever it is inconvenient?
Agile is cargo cult. Customers are not agile to your fuckups. Competitors are not agile to your "scope creep". You know what is the current most agile company in software? Microsoft. You know why? Because no matter how much it fucked up its business is so huge and so vast that it did not matter. It makes money. But even Microsoft is starting to feel the need to deliver as otherwise it is going to become IBM or Xerox.
Agile is like dieting, simple but hard and requiring a lot of discipline. Very very few companies are any good at it but done well, it's a complete transformation.
I think it's more like a cult, where it's supposed to solve all your problems and any problem you identify with it just proves you aren't doing it right.
It is, at best, a different set of trade offs. What it has become is like you said, some sort of cult where management gets everything they want and don't have to pay any costs.
I've worked at two places where my tech lead at least recognized that if scope or requirements changed then deadlines changed. Now I am at a place where agile is just a word thrown at any problem and now we have things like being asked to integrate third party tools that we don't receive until a week before the deadline. My team stayed till 2 am and was back in at 9am the next day and _literally no one_ saw a problem because it's "agile" and that's what you do when your agile
I've experienced "no methodology; just people kind of describing what they want and you make it up as you go along" and Scrum and I prefer the former, but I suppose it's possible that someone out there is doing Agile in a way that is better than the one I learned in a bunch of excruciatingly boring training sessions from consultants.
e: Actually I did Kanban too and that was OK, but that is a lot closer to the "no methodology" thing and anyway doesn't involve you making decisions like "oh, can't start working on that, because the sprint is almost over."
Kanban is very much Agile. Scrum can be implemented in a variously heavy to lightweight way, though FWIW I found having leftover time at the end of a sprint that could only be used for non-business-facing work (e.g. improving the build system, refactoring of code that wasn't immediately being worked on) to be very valuable.
I guess the cynic in me finds it predictable that most Agile shops (at least IME) would be doing Scrum and not something like Kanban, even though it largely works against the supposed core values of Agile.
Yep Kanban is the way to go, focus on flow, small batch sizes, reducing waste of wait times and handovers. Look at cumulative flow and rightsize stories instead of fretting over estimation, points, burndown, and all that mini waterfall that scrum seems to entail. Takes most of the drama and hysteria out of delivery.
Ultimately it makes no difference whether you're doing "story points" or estimates in units of time. All that's going to happen is they'll be converted to units of time in a way you don't quite understand. It's just so naive to believe any of the Scrum promises.
It's why we always do rightsizing and never numerical estimates. You can calculate delivery dates by counting stories * average story time - very fast, very simple, and amusingly at least as accurate as detailed time estimates. Has an interesting side effect of tying scope to delivery. So if you want to reduce delivery time, it's clearly understood as under control of stakeholders and done by dropping stories. If you can't rightsize to a reasonably narrow range (we use 1-5 days) and have to estimate (e.g. sifting stories for prioritisation purposes), t-shirt sizing usually works ok and gives the required info without opening it to abuse.
