Is high speed good or not?
We generally believe that it is. But it’s not all that simple. True, if you ask any given enterprise whether they would like stuff being delivered faster or slower, they will pick “faster” every time. Here’s an important question though: the speed of exactly what are we so concerned with? Feel free to fill out the blanks:
We are trying to accelerate the ______________ in our organization.
What did you put in there?
Here’s what’s interesting: for very many organizations the phrase in the blank is “scope delivery” or “delivery of functionality” or “delivery of features”. (Note that here by “delivery” we mean development and deployment, altogether). Now, I wrote about this a number of times before that scope does not equal value and trying to approximate value by scope is a dangerous business as, generally speaking, one has little to do with the other. Today’s solutions are so complex that any significant step forward in the development of new functionality pushes us into an unknown territory where all we have is assumptions that require validation. Will the users like the new feature? Will it solve their problems? Is this new feature-set a sufficient reason to increase the license cost? Will this new caching algorithm work well under various production scenarios? Will our business partners find this API easy to use? Will this UX simplify conversions or we will keep losing potential customers? Etc.…etc. The scope itself has little to do with this. Moreover, the more you add to your solution, the more difficult it gets to add new functionality in the future. So, if we stuff our system with much fluff, then when the time comes to implement something really important, it will be a very difficult and painful process. So, takeaway #1:
We want to speed up the delivery of actual business value, not just any functionality.
That sounds better, doesn’t it? But here’s the catch: how do you determine what’s more and what’s less valuable? Well, someone may suggest a kind of prioritization process, and that immediately makes us feel so much better… while it probably shouldn’t. Here’s why. Let’s ask ourselves, how are those priorities being assigned? Well, a few decision-makers get together and figure it out, right? Well, too bad, because that’s the easiest path to indulge confirmation bias in full. And then whatever we call “value” is no more than our wishful thinking. Since when an isolated, internal opinion is a sufficient substitute for customer feedback or proper technical or market validation? But what a great sense of false security it creates!
An organization needs to establish a process by which they properly learn what’s value and what’s not. Instead of sweeping assumptions under the carpet, those assumptions need to be properly managed. In some cases, it means consulting with the customer and end users, in others – test-driving a prototype, yet in others a fully functional system for a subset of users and so on. And yes, sometimes there will be no other choice than to learn by doing, but that has to be clearly understood by decision-makers and treated respectively. Hence, takeaway #2:
The speed of value delivery is contingent upon organizational learning.
Now we are getting somewhere. Learning requires feedback cycles that cut across organizational levels and even the organizational boundary itself, therefore involving external parties that pay for, support or use the solution. In fact, this second statement is paramount: if the organization cannot learn fast, but keeps pushing hard in terms of delivery speed, it turns into a high-throughput poo-poo delivery vehicle.
Now’s the time for a few coaching tips (again, as always, mind your context when applying anybody’s suggestions):
- Disrupt the conventional isolated decision-making pattern by involving people from different levels (and, importantly, from outside the org.) as part of the routine.
- Coach the management to encourage alternative thinking and disagreement. Creating psychological safety around it is a primary goal.
- Start to manage assumptions explicitly. They need to be identified and acknowledged, for starters. Imagination is one thing; reality is quite another.
- Establish reliable feedback for functionality already delivered and have decision-makers compare expectations with empirical evidence.
- Coach the organization to operate with thin vertical slices of end-to-end value (emphasis on end-to-end). Move away from deep hierarchical work breakdown structures, as those are optimized for implementation (where we pretend that there’s no unknowns) and what you need instead is to optimize for learning (where you explicitly acknowledge and effectively manage assumptions). In some cases WBS is unavoidable. Then at least subordinate it fully to vertical slicing.