Even a startup cannot do manifesto-agile most of the time IMO, at least not if they have a strong desire to succeed, because they are constrained by the possibility of running out of money in the near-future.

I am dabbling with bootstrapping now that I've hit my financial-independence targets and I think this, along with profitable+small+private+engineering-led software businesses and FOSS, are some of the only environments in which you can engage in true Agile. That assertion stems from the fact that they are not subject to real constraints in budget and resilient to business meddling in things like TTM and MVP.

Is there anything you can't substitute into "Even a startup cannot do X most of the time IMO, at least not if they have a strong desire to succeed, because they are constrained by the possibility of running out of money in the near-future." ?

Not exactly sure what you mean, but most startups operate at losses for a long time before becoming profitable. I explicitly noted that bootstrapped startups with passive income and profitable small engineering-led companies are not constrained by this problem, because their financials support operating indefinitely - but perhaps I misunderstand your point

I've seen a lot of agile shops and in my experience most of them have the right idea and relatively few are really abusing it. The friction with any project, agile or not, almost always boils down to estimation. "When will my product be done?" That's a really hard notion to disabuse regardless of process. No methodology has successfully solved for predicting the future.

of course not. but if you don't follow corporate agile, then you're allowed to make estimates beyond a single sprint. are these prophetic? only in the sense of being self fulfilling. we can do is have a rough map of the work and eyeball our progress given the team we have, and try to line that up with the endpoint by working backwards.

this should give us some general feeling about risk. we have lots of ways to repond to perceived risk of failure -

    - pull in a more experienced person to get a read and possibly help with that part
    - shuffle the order of development to try to swallow some of the uglier pieces early
    - talk with product (possibly yourselves wearing different hats), about whether we can meaningfully throw some work off the bus without hollowing out the release
    - thin out some features

and actually probably several more. what corporate agile says is 'this is all too hard, screw that, lets not try to account for individual strengths, and the nature of the development process, and the sensitivity of the markets towards particular features. everybody pick something to work on for the next two weeks...and if that didn't work. well, we tried our best'

And none ever will, but organizations will keep chasing that brass ring.

You’re 100% right. In every case where I’ve been a part of agile, you have someone at the top that’s wanting predictability. If I told them to pick between 5 guaranteed features and 10 features but they don’t have control over the timing, they’d pick the former every time (well they’d try to pick 10 guaranteed, but ultimately they’d rather have predictability than velocity).