Agile is universally applied, which is the failing. SOmewhere in those comments is the gem of the whole thing:
- It's good for interfaces. Specifically, ones that are ill-defined
And therefore, agile is great for moving around widgets, changing CSS / colors / fonts, adding a widget or two, improving validation on fields, maybe splitting a page into multiple. Notice how all those tasks are palpable, pretty simple, well constrained, evolutionary, and steadily improved? Perfect for Agile.
It might be good for some microservice development, but it also tends to make microservice interactions unstable and explode their numbers, and destabilize the apis.
Research, deeply difficult code, inherited codebases, large refactors, architectural migrations (monolith --> microservices, major version updates to platforms, move to cloud), are AWFUL for Agile.
Aside from that, story points, burn charts, velocity charts, fixed sprints, tend to be square peg round holes and big hammers. I can't count the number of times I simply had a "8" ticket that would cross two or three sprints before it was done, and eventually managers just accepted it when I explained what needed to be done. And really, that was still to confining for major major tasks.
Also, QA gets completely squeezed, because the agiles I've seen all assume the QA is done in the same sprint the dev occurred. Wow is that dumb. Because the dev runs long, the QA gets shrunk. Really the QA should occur in the following sprint once the dev deadline is achieved.
There has to be a middle ground. Either you are doing 6-12 month waterfalls, or doing 1-2 week sprints? Come on people. How about 1-2 month checkins?
Sometimes I wonder if software dev orgs could vastly benefit from a bunch of attached "dev assistants" that help write the documentation, track tasks, tickets, etc, and alleviate devs from having to do all that paperwork / distraction. They can function as safe sounding boards, or keep an eye on a bigger picture as the developer dives deep into the tech details.
Managers wouldn't stoop to this. SCrummasters ... kind of ... devalue managers a bit at the interface point with engineers, but not enough to get this sort of bookkeeping.
Like, if you are shelling out 200k for an engineer, wouldn't you rather they work as much as possible on the tech stuff, and leave the bookkeeping to some cheaper person?