The analogy with physics and basically differential equations brings in familiar concepts from the "spherical cow in vacuum" world. If we wanna go technical, then acceleration too does not matter, cause jerk (acceleration of acceleration) matters even more. We could keep going deeper and deeper into derivatives at no gain. You can introduce mass, air resistance and whatever you want, but at the end of the day this is all just an analogy. Getting into technicalities of jargon has no practical benefit.
When people say "velocity" they actually refer to all the "derivatives". Just like when I say my car faster, well it is both faster and accelerates faster and all of those things. A Tesla is faster than a normal bicycle. Faster and "velocity" have mental association and that's all it matters. Changing a the term from "velocity" to "acceleration" and whatnot just changes the label, not practical meaning and what people want to convey.
As if acceleration doesn't have a direction. And how many dimensions does software development have, anyway? Replacing one analogy (distance) by another (mass) isn't going to help.
They typically play a role if you care about how smooth the transitions between two accelerations are (e.g. vehicles)
Similarly designers and engineers look at derivatives of curvature (1/radius) if they want to achieve smooth transitions between curved surfaces (e.g. car bodies).
Cannot speak about motion, but in surface continuity you will also look at higher "derivatives" if you want really really smooth transfers between two curves. So you make the transition of the curvature comb of a curve's curvature comb tangetial or so. There they just call the transitions g0, g1, g2, g3, g4 and so on.
I cannot judge whether snap, crackle and pop are things people actually use when they talk about those derivatives in motion.
There should be a special circle in hell for companies abusing velocity as a metric. Story points are made up points and looking at their velocity or acceleration will result in noise. Managing that noise may look useful, however, it is waste of time. It is as useful as going to the seaside and writing reports on underperforming waves.
What is useful, is to understand why certain task take longer than anticipated and learn lessons from that. Were there hidden requirements or was the task too ambitious and should it have been broken down in smaller tasks.
I know that there are definitions of velocity such as "a measure of the rate at which a development team consistently delivers business value". But I find this definition to be pretty useless in practice, so I ended up landing on a different definition, which is that velocity is "the ability for an engineering team to maintain productivity in the face of changing business requirements".
By framing it this way, I find that velocity becomes something that a team can actually experience, at least informally; and it implies the need to put time towards tools, management and architecture, rather than just features.
> a measure of the rate at which a development team consistently delivers business value
It isn't even usually this, because typically it's _developers_ - not the wider business - who assign point counts to tasks. At the end of two weeks you've typically done about two weeks of work so all that is actually being measured by velocity are the median numbering preferences of the team. eg People who like "fibonacci numbers" invariably achieve a velocity of about 6 * $DEVELOPER_COUNT per sprint.
In order to get a measure of business value you would have to involve someone who knew the relative value of the tasks. Usually that does not happen and agile has at least partially contributed to that by standardising the idea of a development team as being primarily made up of developers (with one token project manager who is there because they know how to manage people, not because they have special knowledge of business value).
Agile, at least as popularly understood, has moved the whole field backwards by entrenching the separation of developers from non-developers. If you try to work directly with the business on a modern agile team, you tend to get rebuked! You've cut your "project manager" (who typically doubles as your line manager) out of the loop and you're no longer making progress on the agreed team measure of story points. Frustratingly, trying to work on business value is de facto non-compliance on many "agile teams".
Yeah - I was quoting the velocity definition given by an article pointed to by TFA. But I mostly agree with you, especially about the identification of business value. My point was that it’s better to have a value that can be measured by the participants (ie, productivity), than one that can’t (business value).
That said, while I am no fan of “agile as popularly understood”, my experience suggests you have the causality backward. Agile is simply a term forced on traditional project managers to make the business sound cool. Nothing is different from the way it was before agile, except the meetings have cool names.
In an environment that takes the agile manifesto seriously, working hand in glove with the business is kinda the point. But most businesses haven’t even heard of the manifesto, and those that have … don’t care.
The things on the left are talked about. The things on the right are measured. What gets measured gets managed and becomes the focus. Is anybody measuring the things on the left?
Can't wait for all the physics concepts & lingo to go mainstream into software companies..
My only hope is the "reduce mass" will serve as a detractor, but I'm sure some slick guy would say "We can use Agile and microservices for that" and then we're back in the hole of tech bs..
When people say "velocity" they actually refer to all the "derivatives". Just like when I say my car faster, well it is both faster and accelerates faster and all of those things. A Tesla is faster than a normal bicycle. Faster and "velocity" have mental association and that's all it matters. Changing a the term from "velocity" to "acceleration" and whatnot just changes the label, not practical meaning and what people want to convey.