Velocity Over Speed, A Winner Every Time

I was working with a group of architects recently who complained that they had to do things faster and faster because if they didn't their 'customers' would simply go to a 'competitor'. This was at a major international company and their 'customers' were employees of the same company. Their 'competitors' were service integrators and vendors.

This situation is not rare. We live in a world that is obsessed with speed. Faster, faster, faster... outcomes don't matter, just get it done. While speed can be a function of value, it always amazes me, that we have gotten so addicted to talking heads.

Enter Velocity

If speed is a measurement in architecture at a point in time (let us say two stories, per week, per developer). Velocity, as in physics is vector-based or directional... That adds an interesting twist. What direction are those stories and is that code taking us? Velocity then is controlled speed. Going fast enough, but not so fast we cannot take a turn.

So for the purpose of this article, velocity is purposeful speed with measures that lead to direction and/or outcomes. In the above example, this would require a sense of the value of those stories. For example, 2 stories with a value level of 1, would be less than one story with a value level of three. It sounds simple? or possibly it sounds silly... because value is not objective. Nor, as we will see, is it easy.

Speed is Not Value and Definitely Is Not Quality

Say I want to produce an item, like a head of lettuce. A good head of lettuce takes time to grow. And that time is expensive. The facilities, staff, electricity, products it takes to make lettuce, the website, marketing, management, and all the million and one things necessary to grow and sell great lettuce. The natural idea is the faster we can grow the lettuce and get it to market, the more profitable the lettuce. Whew! Faster is better... except.

What if the faster product is not the same quality? Giving the lettuce growth hormone and contrived environments and using faster-growing lettuce that is a little tougher, might give us a faster head of lettuce. But how many tradeoffs until we lose customers? When does our lettuce become terrible to eat?

What if we cannot handle faster lettuce? We don't have the storage, shipping, or customer demand to handle or sell the lettuce, so more and faster is not valuable.

And is faster lettuce actually better or more valuable? The annual output would not be that much higher unless we have increased capacity as well as speed. In fact, faster lettuce to market can only be valued based on the time value of money (Net Present Value).

We don't get certainty. We get better at dealing with uncertainty.

So there is the rub, value is HARD. It is subjective dense and complex... but that is why architecture is as much art as science. Value in other forms of architecture holds similar qualities... Is the Sidney Opera House beautiful? Valuable? To some. To others, it may be ugly. So what do we do to get better at this?

Don't Go Back to Slow, Understand Velocity

Precision Bias is the utterly false belief we can predict any time length ever. No one saw covid coming. So every damn prediction at the time did not come true. And while most delays are not caused by such global melt-downs, they still happen. But the addiction to speed itself is one of the largest factors in slowing down our delivery times.

To understand velocity we have to understand value. Both intangible value and direct value. I call this 'soaking in numbers'. When I am with a new client (read my article on clients vs. customers) I like to read hear and learn every value metric they find important. I want mean time to recover. I want the number of new customers per day. I want net promoter scores, profitability, lead times, partner surveys, employee turnover, all of it. These are the language of value that a set of stakeholders uses to describe value. Notice how few of those measures involve speed numbers?

I guesstimate that only 10-15 % of any set of measures will be speed-related. In fact, speed will cause many of those metrics to fail. Too many new hires, too many orders, too many acquisitions.

Regardless of what level I enter a client (from project developer to C-Suite Chief Architect), I will 'soak in the numbers'. You will be amazed at how differently you approach a backlog grooming session, a stakeholder interview, a product owner meeting, an entire program-level investment meeting or even a maintenance task, with these numbers in mind. And that is one of the keys to being a great architect. Or being one at all.

For more on Velocity, read the BTABoK article here: Velocity | IASA - BTABoK

To begin understanding value, focus on the benefits realization article: Benefits Realization | IASA - BTABoK

To contribute to the velocity dialog, contribute your thoughts to the measures database we are compiling in version 4 or become a BTABoK scenario writer (using practical tools in the real world).