[im_down_w_otp]

The problem I witness when the general goal laid out is improving "velocity" tends to be a fundamental misunderstanding of what velocity is.

Namely, velocity is speed plus a direction, and most of the activities that would normally help codify a sane and deliberate direction (i.e. rigorous requirements, rigorous design, rigorous validation, etc.) are all primed to be sacrificed at the Agile altar. What you end up with is just "speed" as a priority.

When organizations have KPIs & OKRs which set "velocity" as a prime directive what that usually means is just "speed". As long as your development cycles are shorter and shorter, then you're rewarded. In these kinds of organizations the incentives align with flailing around spastically, so long as you're doing it 1x a month, 10x a month, then 100x a month. Taking the time to be exactly right 1x a quarter, and then building on that, isn't seen as desirable.

As one would expect, there aren't an enormous number of people who are actually satisfied by doing random crap for a random cause as fast as possible. In fact, that's what machines are for, not people.