I feel like there's this no true Scotsman thing going on with agile. Whenever someone describes their actual experiences with agile, there's always at least one person who speaks up and decries it as as not real agile and what agile should be.
At this point I don't care what agile should be. I just don't want management shoving agile down my throat anymore. I've yet to see it actually improve productivity for any team I've been on. Real agile must be exceedingly rare.
It's not mysterious or confusing. The original definition is at https://agilemanifesto.org/
Similarly, everyone agrees that the Agile Manifesto is the OG source of Agile faith - and then everyone claims their own particular interpretation of it is the True Meaning anyway.
I've heard that one of the benefits of agile is identifying blockers and encouraging collaboration, but I saw much better results from assuming you've hired intelligent adults with work ethic and letting them reach out and collaborate as needed. Daily standups, sprints, boards, planning, etc. are great in a low-trust environment where you can't be sure people are doing the right things. But if you've hired self-directed people, that stuff just gets in the way.
I've known talented devs who are great people who still need more oversight than you describe. Usually they are ~5 years off from being full-trust, yet still valuable team members. Yes they benefit from daily standups.
There are for instance much better allegories for performance programming in the notion of an apple tree than “low hanging fruit”. Picking the low hanging fruit is just as wasteful a process in both domains.
Fast food restaurants don’t prepare food when you order it. It’s already mouldering in the back. They only make it on demand if you make a special request or they already fucked up their inventory estimates. It’s a lean process not an agile one.
And if you don’t think real restaurants sprint, maybe you should watch The Bear.
> Fast Food > Here, we develop in "agile" sprints. Working software is developed at the fastest pace possible, and all bugs are to be fixed later.
> Home Cooked > Here, things are slower, more thoughtful. More waterfall-y.
While Sprints is a term that sounds like fastest pace possible, that is not what the term means; and a key part about waterfall vs agile is that waterfall IS NOT more thoughtful, but all planned up front.
Both methodologies can create bugs, or deliver features faster than scale can be thought of and deliver features faster than can be tested.
If we remove the quotes from "agile" we actually get slower and thoughtful. A key part of that is measuring (training, interviewing, analyzing). An agile process should build a feature, release that feature, interview users, analyze system behavior, iterate by improving user's goal, adding appropriate scale, iterating by removing unexpected errors or behavior.