You shall know our velocity
But we have no idea when this will ship
First off, apologies to Dave Eggers for borrowing the title of one of his best works. Highly recommended!
This is a post of exasperation. It may also be one of my shorter ones.
In a nutshell: that word, velocity, is killing me.
And somehow, within the sample space of product and tech leaders, I don’t think I’m alone in feeling this.
Thought experiment: here’s 3 fictional graphs:
All parameters held constant (same team, same toolchain, etc.), which one is your favorite?
I daresay many people would go with B. Up and to the right, right? Mostly?
For me it is C. And to be repetitive, within the sample space of product and tech leaders, I don’t think I’m alone in this.
Why? It’s the unit systems.
Unit economics
Before being swayed by the trends in these plots, it’s worth looking at the axis labels. It’s story points vs week (or some measure of time, like sprint).
This is the first source of my semantic frustration, and where the word velocity wreaks its unique brand of havoc. Per the Encyclopedia Brittanica, velocity is:
a quantity that designates how fast and in what direction a point is moving.
Units: meters per second, miles per hour, furlongs per fortnight: distance over time
So, armed with an unshakeable recall of high-school Newtonian mechanics, the powers-that-be seamlessly map “velocity” to “speed”. Improving velocity this becomes about shipping faster. Missed deadlines mean your team has a sub-optimal velocity. Le-sigh.
On the other hand, regarding “sprint velocity”, the Agile Alliance says:
At the end of each iteration, the team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity.
Units: story points per week, story points per sprint: volume over time
In other words, putting aside the delightfully ambiguous voodoo of “story points”, it is a quantification of the team’s output capacity.
Aside: It’s worth noting here that the “volume” here is not necessarily code volume, but rather an abstraction representing functionality or complexity. A “5 point” story may take 5 hours of brainwork and yield less than 50 lines of brilliant code written in less than 25 minutes. That’s still a big “volume”. Yeah, it IS voodoo.
Either way, it has little to do with shipping speed. This is where Agile blew it on jargon. While these two have a (somewhat tenuous) correlation, they are not the same, at all. They answer different questions. Velocity answers “how much software can your team produce in time X”, as opposed to shipping speed, which answers “how fast can your team launch Y to production”. A bad question to begin with, but more on that later.
Tries to answer anyway: sprint velocity by itself is woefully inadequate to answer anything, being as it is but one of many many variables in the bizarro multivariate Markov Chain or Martingale or whatever Sorcery it is that attempts to make software estimation “predictable”. Channeling the old SAT/GRE prep days: Predictability:Stakeholder::Pipeweed:Hobbit
We love predictability, however illusory it may be. Works wonders for board decks.
The Illusion of Predictability
Swinging back to those velocity charts from before, this probably clarifies why I prefer C.
Unlike most other flatlines, this particular one is delicious. It implies consistency. Consistency breeds the fabled predictability. Flatlining tells a comforting story, that the team is finding its rhythm, working well together. That the people variable in the Markov chain is stabilizing, and we can look at other obstacular variables. Yeah, there’s no such word as obstacular, but there should be.
Aside: At this point I should apologize to all pure and applied mathematicians specializing in stochastic calculus for abusing Martingales and Markov Chains.
Let’s take this further, while we’re wandering in our Holy Grail fevered dreams. Here’s an even more idealized graph, with the team held constant:
Now my comforting story from earlier has become a heartwarming Christmas miracle tale that would make Frank Capra feel like Orson Welles. A healthy, predictable improvement in velocity over time. I’m positively salivating. I’m desperate to know what obstacles we removed that enabled the same team to produce more.
But here’s the catch: none of these.. velocitations.. will help me answer a common inbound question of the shape: “How long will it take us to ship X?”. Yeah, there is no such word as velocitation, but there should be.
My answer would still be the one that triggers white-knuckled fury in the listener aka stakeholder:
I can’t really say
Or if I wanted to temper it, sand it down, couch it, or apply some other metallurgical softening to it:
It depends.
“Depends on what?” they say. “Well, there’s a lot of other variables” I say.
At this point the battle is lost. Engineering is the bottleneck. Our velocity sucks. It’s the same story, over and over. Everywhere. No team is immune.
And it will continue being so. Why? Two main reasons:
There are, as I said, other variables
It’s the wrong question
Other Variables
Team capacity tells me how much, but not what. In a perfect world, Team A working on Problem X is wholly, solely, completely, consummately, uninterruptedly working on nothing else but Problem X, with no distractions and no external dependencies.
Except the last time that sort of focus happened was probably that term project for CS412 in your senior year (maybe), or the thesis you worked on in grad school, or, more recently, the MVP your 3-person Delta Force built in the garage to take you from 0 to launch and land your Series A.
In the messy real world of scaled commercial software development, your team will be yanked non-isotropically in several directions, often concurrently:
Context switches. Production issues, emergency hotfixes, no-one-else-knows this-better-than-me-so-I-gotta-fixit (which is a different problem for a later post). The more senior you are, in tenure and experience, the more likely you’ll be yanked in this particular direction. This is unavoidable, and the most disruptive yank of them all.
Debt, and unintended consequences. Touched briefly upon this in tech debt. The bigger the platform footprint, and older the codebase, the bigger this issue gets. Software is entropic. Something here will almost surely cause a weirdness over there. And you can’t estimate that upfront, it’s an unknowable.
Internal dependencies. “Still waiting for greenlight on designs from Cassandra in Compliance”. “Ebenezar in email marketing is on parental leave, no one else knows what the dynamic variables for this email are.” “Pollyanna is still redlining the MSA”. Ring familiar?
Software creation is not the only activity that ships software products. Yet it’s the only one quantified and measured and held accountable. I’d like to see velocity charts for marketing or legal too someday. Or more ideally, a chart that tracks the work of the whole Problem X team.
External dependencies. Yeah, you try and speed up the work of that guy in Nebraska (again). There are parts of the build we simply don’t have control over. ‘Nuff sed.
I really do like that meme, sums up “external dependencies” beautifully.
Toolchain and process efficiency. Velocity measurements often end at
Ticket.status = Closed. There is a good bit of journey left for code to travel before it hits production. And even more before it reaches everyone (if you’re doing things right with feature flags and blue-green deployments). Here’s a sprinkling of things to look at:How efficient is your development environment?
How accurately does it reflect prod?
How fast can you run end to end tests? Regressions?
How long does it take to do a full build?
How quickly can DevOps provision a new cluster?
How efficient and automated is your shipping (CI/CD) pipeline?
How well are all the parties involved in the creation and promotion communicating with each other?
Bottomline: Velocity isn’t everything. Your team may be consistently outputting same volume, but it may be in service of 7 different things in addition to the one thing you’re trying to launch. Look at the whole pipeline for diagnosis and look beyond product and engineering.
Wrong Question
There’s the rub. No software team or leader has escaped being at the receiving end of “How long will it take to ship this?”
It’s the wrong question.
On so many fronts. It is inefficient, demoralizing, and ultimately unanswerable in any meaningful way.
It’s inefficient. Boxing the what and figuring out the how long is a losing game. All it breeds is exasperated exchanges that waste time and raise tempers.
Plus you miss out on what software engineers do best. Hint: it isn’t coding.
Dreading to tread into mythical man-month territory here (box, Pandora, etc.), but the refrain that often follows close on the heels of it is “can’t we put some more people on it?"“
It’s demoralizing. The question is transactional, not collaborative. Your tech team is not an agency bidding for the project. They are a part of a team that solves problems and moves the business forward. This framing makes them feel like code monkeys taking orders from stakeholders. No one likes working like that.
It’s unanswerable. Software, beyond a trivial point, is inherently inestimable. Any answer in the form of a timeline is either a massively buffered SWAG or a bare-faced lie (because Other Variables above). And yeah, the agency above is swagging and buffering as well, but they don’t have a choice.
This is why I was never a fan of farming out bits of dev work to an agency, outside of well-bounded, well-boxed efforts that have a beginning and an end. Grudgingly at that.
So, is there a “right” question? Or is it all just wtf-land over here?
There is 😎. In fact, I mentioned it earlier in this post, in passing. Just turn things around a bit:
What can you build in N weeks?
To decorate it a bit more:
We want to build a product or feature to do X, or test theory Y, or improve KPI Z. Here are some initial thoughts on a feature. What do you think? What can we ship in N weeks so we can start testing and refine?
Here’s what this reframing does:
You boxed time, not product. This makes actual mathematical use of that mythical velocity you’ve been measuring.
You turned your software engineers into problem-solvers, because that is what they do best, not coding. Coding’s the easy part.
You unified your product, design, and tech (and ideally other) teams into one problem-solving SWAT unit by bringing the tech team to the table. That is an empowering concurrent engineering move. Everyone is engaged, excited, collaborative, non-transactional.
This was the whole damn point of measuring sprint velocity to begin with!
You have a much higher probability now of actually shipping something in the time box, or damn near close to it, because the engineers played a role in defining the what. While this may not immediately deliver results right off the bat, it will be the beginning of a much healthier and collaborative process. And it will define an engagement template that, if sustained, is virtually guaranteed to keep improving delivery timelines and quality.
Improving speed and velocity
Returning to the velocitous (another word that doesn’t exist but should) theme of this post, can we improve it? Can we get a given team, all things held constant, to produce more software over a given time? Aka can we get to that Christmas-miracle-tale velocity plot? And can we improve the speed with which we ship stuff?
Yes. Yes. And yes.
Let’s assume you have the right team assembled. Talented, team players, like each other, work well with each other, engaged, motivated, all that jazz. (If not, well there’s your problem.)
Once you have that team:
Give them a problem to solve.
Give them air cover.
Get out of their way.
Over time, they will:
Get better acquainted with the software and the toolchain
Get better acquainted with each other, and find their rhythm
Get more experienced individually (this is what career growth is for - it’s the most symbiotic phenomenon in a work environment).
Get better acquainted with you, their leader(s). They will tell you what’s impeding them, what’s holding them back. They will tell you about the “other variables”.
Now just solve for the other variables 😉.
In all seriousness, this is actually where speed improvements come from once you have the right team and team dynamics. And while those are not easy problems to solve, they have proven solutions that just need a will and commitment (and often a budget) to execute on.
Specifically, in my experience, the single biggest disruptor to shipping speed is context switches. There’s enough there to merit a separate post, but the more you are able to enable uninterrupted focus, and channel your stabilizing velocity towards fewer things. the exponentially more you improve your odds of improving your shipping speed.
Which is not the same thing as velocity, dagnabit!
Post Factum
I guess the post wasn’t so short after all.
On a pseudorandom note, wanted to share a line in the book quoted above (who’s title I have borrowed for this post), circled it in #00d05c below:
Reminds me of a dialogue I have had way too often with stakeholders:
SH: When will it be done?
Me: We haven’t started yet.