One of the greatest challenges to traditional software delivery thinking was the revelation that you can deliver software quickly without causing instability. The speed-versus-stability trade-off was so widely accepted that even a decade after the myth was busted, many people still believe it.
For those who have accepted that you can move fast without breaking things, a second myth is emerging: The myth of speed.
When you look at teams that deploy frequently with short lead times, you’ll find they are generally more successful than those who work in larger batches. This checks out when you consider the additional work large batches cause. There’s also a benefit to the automation you introduce to achieve higher throughput.
But if you think speed alone is driving the success of these teams, their products, or the organization’s market share, you’re making a common mistake.
You can develop a better understanding of the broader factors that contribute to success using the Bullseye Model, which captures the nuance of product velocity.
A quick archery lesson
Many sports present a target with a bullseye, but we’ll use archery as an example today.
When you practice shooting a bow, your goal isn’t to hit the bullseye (though that will become the goal later). Instead, you should develop consistency so your arrows land in a tight group. Until you can consistently group your arrows, any bullseye you hit is chance, not skill.
Much of the skill in archery comes from the discipline of form. You have to develop consistency in where you place your feet, how you hold your body, the way you draw the bow, and how smoothly you release the string. You repeat this by making very deliberate moves many times over, working through a checklist in your mind each time, until it becomes automatic.
Once you’ve developed these skills, missing the bullseye becomes part of the feedback loop. When you know you’ve got all the movements right, you’re able to attribute any drift to other sources. You can now adjust your aim to compensate for the many variables, like wind speed, moisture in the air, and distance, and you develop a feeling for when you’ve damaged an arrow and need to repair it.
If you were betting on an archer based on scores, you’d likely pick the left-hand target. You now know that, over the course of a whole competition, the right-hand target was made by the archer more likely to win. When an archer can group their arrows in a tight bunch, they can move that group closer to the bullseye and achieve far higher scores than those hitting the target randomly.
Why speed isn’t enough
Let’s return to the topic of building software. We need to establish why speed alone isn’t a sufficient strategy. If you’ve been following the research, you’ll be familiar with the insight that deploying more often with short lead times makes your team, software product, and organization more successful (source: DORA). Interpreting this as “speed equals success” is a simplification of the true picture.
Many teams and organizations are working hard to improve their software delivery performance without realizing a crucial element is missing from their approach. Alongside the smooth flow of changes, you need to develop a deep understanding of the user, their goals, and what’s causing them problems and friction.
The research captures this in a construct called “user-centric focus,” and the Bullseye Model is how you navigate it.
The bullseye sits at the center of the target. It represents an absolutely perfect product-market fit for your software product. If you imagine the best product your customers could ever want, that’s the bullseye. Except you can’t imagine it, which is why you need to apply the Bullseye Model.
Product velocity
There are infinite paths for developing a software system. The two most interesting are where you are now compared to the ideal product you could build. The concept of the ideal product is asymptotic, but it’s better, faster, safer, and cheaper than your competitor’s products.
To map product velocity, you need to know your starting point. What you’ve built likely isn’t the absolute best product, so your customers’ needs are not fully met. Your starting point will be somewhere other than the bullseye. It may be close to the gold circle, or it could be wallowing in the very edge of the last white one.
From this starting point, you create a roadmap, which is your hypothesis about what will make your software look more like the ideal product. Each roadmap entry is another arrow hitting the target, and each time you shoot an arrow, you have the opportunity to observe where it landed.
The line between the starting point and the new arrow has a distance and direction. This is your vector, telling you whether you’re heading in the right direction and how quickly. You have to watch both, as only a careless organization celebrates speed without paying attention to direction.
The direction of the vector tells you how well your roadmap is servicing the hunt for the ideal product. If the vector points to the bullseye, your assumptions were perfect. More often, you’ll find you’re making less efficient moves.
When you move away from the bullseye, your hypothesis is invalid, and you need to adjust course. You might back up and try a different approach (returning to the previous starting point), or incorporate feedback that changes the outcome (continue from where your arrow landed, hoping to flip the loss to a gain).
When speed does matter
On the Bullseye Model, speed refers to how quickly you can prepare and shoot each arrow. We can apply the lessons from the research here, as we don’t want throughput (lots of arrows) without stability (hitting the target).
Speed does matter, but it’s not the goal. Your ultimate aim is to reach the bullseye, but being able to smoothly and quickly deliver arrows creates more opportunities to check your vector and adjust course. Crucially, when you start trending away from the center, you can rapidly reverse course without over-investing in the wrong approach. You might start building an “offline mode” only to discover users are confused by how you’ve implemented it, or that they don’t value the idea at all and would prefer to be notified when they are back online.
Any speed you have in excess of your ability to check your vector and change course is wasted, as it’s as likely to move you rapidly away from the bullseye as it is to move you closer. You need to develop feedback cycles in concert with your software delivery throughput, while maintaining stable operations.
Moving in the right direction is the primary concern and high-throughput is a valuable way to check your vector more often.
AI makes deployment pipelines crucial
The introduction of AI-assisted software development means teams have the potential to increase their throughput. There are preconditions for this to be true: the techniques and practices described in Continuous Delivery, as evidenced by research programs like DORA.
When you increase change throughput, you must adapt to this rate of change in other areas, or queues will eat all your gains. Manual stages in your deployment pipeline need refinement. You may automate, augment, or prioritize them, but leaving them as they were before AI-assisted development is not an option.
Deployment governance has become crucial in regulated organizations and those working at scale, as fragmented governance processes will result in a total loss of all return on your AI investments. Your default path to production must be the easiest, safest, and most compliant way to deliver changes, with no exceptions or expediting.
The Bullseye Model also reminds you that the rate at which you can collect and absorb feedback is a crucial consideration of how quickly you can introduce changes. If you can’t tell if a change is moving you toward the ideal product, you’re simply spinning out of control.
While our competitors are counting token use, pull requests, or lines of code, the thing that we should focus on above all else is how rapidly we are closing the gap between where our product is today and the ideal product described in our roadmap.
Happy deployments!
Tags:
