Sometimes we talk about “velocity” in software, as “how many story points can we do in a sprint”–er, I mean “the rate at which a development team consistently delivers business value.” Sus.
I remember velocity from back in my development days. Velocity is the rate of change of position, so: how fast something is moving. Like this spherical cow in a frictionless field: from when it leaves the rubber band, how long until it reaches the gate? Depends on its starting velocity. If the field is 120m wide and the cow has a velocity of 30m/s, it’ll reach the gate after 4 seconds.
Except! Velocity is more than a number. Velocity has magnitude and direction. Looking at this field in 2D: if the velocity isn’t right toward the gate, then the cow slams into the fence instead (after slightly more than 4 seconds).
Velocity as a single number only makes sense in 1-dimensional space. And software is a many-dimensional problem. It has possibilities we haven’t thought of yet. Like this cow hasn’t considered that there are other cows in the field, and rocks, and oh look the truck isn’t at that gate, it’s at a different one.
The cow can’t reroute, because it only has velocity. It doesn’t have acceleration.
Acceleration is the rate of change of velocity. A nonzero acceleration can change how fast we’re going, and more importantly: it lets us change direction.
How do we get acceleration? Newton’s law says:
F = ma
Where F is an external force applied, a is acceleration, and m is mass. Or, solving for acceleration:
a = F/m
To get more acceleration, we can increase the force or decrease the mass we’re moving.
What is the mass we’re moving? In software, it’s the system we’re changing and the social system we must change it in. The messier the code, the more coupling, the harder to deploy, the less familiar, the harder to see inside, the more people involved–the larger its mass.
Also: the more full-featured it is, and the more valuable, the larger its mass.
That’s not avoidable: the more valuable software is, the more people are using it, the bigger the expectations held by people and other software. If we have no users, we can wipe out the DB to change the schema. If we have precious customer data, we have to think about migrations and backwards compatibility and scale and and and. We have to do more than write code; we must design change.
And then there’s the Invisible Requirement attached to every new feature: “…and everything else still works.” The more capable our software is, the harder it is to add or change a capability.
Therefore, our work naturally increases the mass of software we’re moving. Acceleration gets harder, and our work slows.
Can we increase F to compensate?
No. In software, the force moving us is (at best) intrinsic motivation. Applying external force like hiring more people, working longer hours, or scaring developers with weekly “code reviews” all have the effect of increasing mass even further. Collaboration overhead, tiredness, and pressure lead to lower code quality, making every capability heavier.
Therefore, improve acceleration in software teams by doing work to reduce mass.
The inertia of our system is lowered by activities like
- clearing the path to production
- refactoring to more readable code
- evolving architecture to suit current complexity and scale
- upgrading libraries and infrastructure
- sharing knowledge among the team
- instrumenting for observability
- acting on incident reports
- automating repeated tasks
- fixing the most common errors in your exception tracker
To maintain and even increase velocity, don’t do stuff to increase your velocity. That slams the cow into the fence faster. Instead, expect the team to spend some effort on acceleration work. Remove the obstacles we encounter, and interact carefully with other cows. Redirect to a new target as we learn more about our customers.
Note that none of these activities are forward motion from the perspective of Product. They can’t be: adding capabilities always increases mass. These different activities fight against the natural ossification of a codebase.
Wait, there’s one exception: sharing knowledge among the team. This is nicely accomplished by ensemble working, which also gets coding done. In ensemble working, every decision is voiced before the typist of the moment changes any code.The common ground established by working together like this leaves the team in a better state for future changes.
Acceleration work is not a full-time job. It is best done from within the system. (With managers and product managers working outward to reduce externally supplied pain.)
Spend your time and attention on overhead (can’t reduce all of it), implementing new things, and some acceleration work.
The spherical cow must grow legs.
TL;DR: To change velocity, don’t apply more force. Work to reduce mass.