Everybody cares about the speed of value delivery. And why wouldn’t they, it makes so much sense. The higher the speed of value delivery, the more value you can deliver to your customer, the better the business outcomes. Well, it is, but only if you understand what it really means.
First and foremost, it’s not “speed of delivery”, it’s “speed of value delivery”. The difference is everything! You can actually learn to be faster in terms of development and deployment of new scope (and some organizations do), but what is being delivered may have little-to-nothing to do with value: the functionality produced may not be something customer wants or likes or finds useful. Or, even though customer likes it, it produces no economic benefit to your organization and sometimes even on the opposite – leads to negative economic outcomes. So, takeaway one: speed of value delivery matters only when what is being delivered is valuable. Seems trivial. But isn’t so in a real life. Often it is automatically assumed that “what we deliver is a value” and the only thing we need is “to speed up”. Big mistake and often leads to poor results.
Two… Once we’ve realized that value comes first, we naturally begin seeking faster ways to create and deploy it. And this is where things get a little tricky. We used to this common perspective: stickies (that represent valuable backlog items) moving left-to-right on the board. All you need to do is make them move faster, right? Well, actually it is not in software and systems development world. To understand why we need to look a little deeper into what is contained in those items. But first, let’s begin with a different case where moving them fast left-to-right makes a lot of sense. That would be in the case of a predictable environment. In that case, your backlog items are containers of value and your job is to drive them left to right through the process as fast as you can.
Repetitive processes or processes composed of a relatively small set of basic variations are usually like that and that often is the case in manufacturing and logistics.
What’s different about software and systems development is a significant amount of uncertainty involved. By definition it’s not a repetitive process, composed of a small set of basic variations. Instead, it’s an inherently complex process that inevitably contains impactful unknowns. The “speed of value delivery” is now not all about moving backlog items left-to-right in a fast manner. That may actually be detrimental. Different thinking is needed. Let’s start with updating our model with more adequate for this type of environment:
Backlog items now contain not only value, where we have strong reasons to believe that such exists, but also unknowns. Unknowns may relate to any aspect of development, such as whether this is the right requirements, whether the architecture will work, implementation, etc. etc. Importantly, unlike in the previous example, the actual content of a container is changing throughout the process itself! New unknowns transpire, existing ones resolve, producing value or damage, respectively:
A simple example of such progression could be as follows:
Our backlog item is a product feature “horizontal browsing of a media collection on mobile devices”. There is certain strong belief at the beginning that it has some value to the customer as it creates a more engaging user experience. But there’s one big unknown – this hasn’t been implemented yet and nobody knows what to expect. Over time, it turns out that the unknown resolves into damage: it doesn’t appear possible to make this a smooth movement; besides other problems occur like automatic shift of the slider after a media item was opened, watched and closed. And so forth.
Now it is obvious that our goal is not to get a backlog item as fast as we can across the finish line. What we would like to do is to 1) achieve high business value for an item and 2) do it fast. Generally speaking, the speed with which backlog items are moving through the system is no longer a key indicator of value throughput, as the actual content of those “containers” changes. Therefore, high-value throughput requires effective progression of backlog items “content”, rather than just quick execution of the initially planned work. Trying to make it faster may actually have an adverse effect on value.
Managing unknowns becomes critical to maximizing value throughput. “Managing an unknown” means devising a strategy of dealing with the unknown in a way that provides a better outcome. This brings an important perspective: the flow of value can rather be thought of as a flow of unknowns from identification to effective resolution in the form of business value.
By Alex Yakyma, Org Mindset.