In our very first public workshop on 25th April 2023 in our series covering the VSM Implementation Roadmap, we addressed the “Identify” step. It was a very lively session, with many more questions than we were able to address in the session.
In this post, Steve answers the remaining questions.
Questions:
Would you say that the customer journey is what Scaled Agile calls an Operational Value Stream? If not, how are they different?
I wouldn’t say so, no. They do seem to conflate the model of a customer journey with an operational value stream (OVS) in their documentation (specifically with the consumer loan example). I think that’s problematic. I think a value stream should primarily reside within the control of the organization. There are many reasons why loan repayment makes for a poor value stream. For example, a loan can be repaid on various terms (or paid off abruptly). This renders lead time useless. The business benefits from extending the loan period and any number of other conditions that nullify value stream performance measurement. The same conditions affect the ‘Software product’ OVS. They are better suited to customer journey mapping and measurement, along with all the practices that support it.
I don’t actually believe operational or development classification is valuable. I think any stream can be more operational (stability focuses), or more developmental (disruption focused) in orientation. I think the orientation changes over time. Every stream starts as developmental. Conditions or strategy can dictate a shift suddenly or over time.
The bottom line is that if the customer is moving through the flow of activities, it’s a customer journey. If work is moving through the flow, it’s a value stream. If you’re interested in guiding principles for identifying value streams, we’ve got a full write-up here.
You can read more on various perspectives on Customer Journey vs Value Stream here.
You are talking a lot about software but what about manufacturing? Is value stream identification the same?
In manufacturing the identification is simpler in that it’s less common for products to be batched together into a large release, be combined with a service, embedded elsewhere, or split between business and retail customers. As a result, it’s much easier to both trace work forward to a delivered product (without having it branch off) or backward from a delivered product. Software can be more complex, obscured, and fragmented because bits and data can be copied, mixed, integrated, and delivered any number of ways. That’s why I advise to consider a specific customer outcome unless there is a clear catalog of distinct products and associated teams to work from.
There are other fundamental differences between manufacturing and software that can help guide your identification efforts. Manufacturing is primarily an exercise of replication and delivery. You design a part once and create many copies that need to be assembled and shipped to customers. In software, the part is different every time, and the assembly and shipping is practically automatic.
Customer outcome first works when you are creating a new value stream. However, in most cases, value stream already exists. So you need to identify the value stream first (trigger and value as boundaries) and then map it to understand and improve it. Thoughts?
You definitely need to establish a trigger and delivered value as boundaries.
I don’t think there’s any value in creating a new value stream in any case. I think the job of finding product/market fit demands something closer to ‘any means necessary’ until the demand has been secured. Once that’s stabilized, you have a value stream, but it’s probably a mess. It likely delivers multiple products (or variants) to multiple customers (large/small business, etc), which all impacts how you might design or improve that value stream in the future. Given all the variations present, I find it helpful to pick a single customer type and value delivered in order to focus on a single stream. It’s often the case that we need to disentangle a monolithic value stream that’s trying to do too much, and mapping a stream in that scenario can be very messy and filled with ‘it depends’. If the path is clear, the simplest identification is by product, but in organizations that are new to value streams, I find there’s often a lot of ‘it depends’ that demands a more specific target.
Your Value Stream may have a longer outlook of maybe 2-3 years but we need to break it into OKRs which are more short-term right?
It’s not quite clear what ‘outlook’ refers to here, but I hope it’s safe to assume it’s referring to the lifespan of a value stream. In that case, there can seem to be a real conflict in time horizon between quarterly OKRs and the full life of what the OKRs are serving. What’s important to note is that the vision for a long-term future can guide short-term goals. If I want to reach a mountaintop, I can work backward to plan my first rest stop on the way. Beyond the rest stop, I can use a map and compass (or GPS) to track my progress toward the key milestones. OKRs can serve as those milestones and progress indicators.
Let’s consider we’re talking about the span of an extremely long lead time just to cover that possibility. The length of the value stream can certainly be challenging when you aim to improve in the short term! If the value stream takes years to complete, you may want to begin by targeting your OKRs by simply understanding and mapping the stream by whatever means you can collect information. Even without a full map, you could survey contributors and systems to understand the stream or look to gather recollections and data from a previous iteration. Once you target an improvement, it may not be necessary to witness the ultimate result of efforts if you identify key results and metrics that signify positive progress.
In any case, this exemplifies a major flaw with OKRs. They can easily incentivize short-term results. It takes careful consideration to craft OKRs that serve the long term while satisfying the short term.
Isn’t the Development Platform a product or service used by customers (Agile dev teams)?
A development platform is often used by internal product development teams, but the customer could also be partners (such as Salesforce app developers) or external customers (such as in the case of AWS).
You can read more on how I see the relationship between platform streams and product streams here: https://www.vsmconsortium.org/blog/is-platform-engineering-a-value-stream
Why not start with the products an organization offers its customers? Then identify the development teams that are needed to develop or enhance those digital products.
If you have a mandate or goal to identify value streams then that would be an easy start. In most cases I’ve been called in to assist with identification and mapping, the identification and mapping wasn’t the goal. Goals are often business or customer impacting, such as improving time-to-market, lowering costs, reducing frustrations, simplifying operations, etc. In these cases, there could be dozens of products and streams involved, so picking a single or batch of products won’t necessarily connect to the desired outcome. If the goal is to more effectively develop a specific product, then that would certainly be the place to look!
Having a large portfolio of products also means you can’t typically map them all, so it helps to be able to choose the best combination of impact vs effort. Working backward from customer outcome helps choose a product and stream that fits the criteria.
Comments 0