[SamWhited]

I completely agree; it also has the effect of making software worse, as far as I can tell. At the last few mid-to-large sized tech companies I've worked for I've watched project and engineering managers push hard for more velocity trying to get their bonus. Eventually they start telling people to take shortcuts, or rewarding the developer who gets things done faster but, as an example, doesn't write any tests. They then get mad at the other devs who won't approve their patches during code review or end up spending their time fixing the bugs in prod created by the developer being rewarded for "moving fast". The pressure on the managers trickles down and the software ends up being broken.

[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.