Value Stream approach adoption

This is a great question and it's much more challenging with knowledge work than manufacturing. This is one of the main reasons why I started doing outcome mapping before value stream mapping. By starting from what we want it's easier to discover what's involved in the current state, which is our best starting point to get to our desired future state.

I think there are two separate questions hidden here. 

1. How do you define value streams across the entire organization? Based on a desire to understand your environment.
2. How do you target the right value stream based on a specific challenge or opportunity?

Part of this is answered in 'How Detailed Should Your Value Stream Be?' here:

When we start to look at value streams in an organization, the higher the better. Once we've identified our area of influence, it's ideal to review a high-level value stream just to get our bearings. This often takes the form of a 1-2 hour videoconference call, but the ideal case is that we run a full value stream definition at the highest level, then drill down as bottlenecks are discovered.

By starting as high as we can, we accomplish a few key wins early on:

• We get a clear example stream we can share with a larger team.
• We reconcile some assumptions about how we create value.
• We share an early alignment on scope and boundaries to save time later.

I'm not sure what you mean by a depth-first search but I'll assume you mean what level we want to look at (operational or development, and deeper if necessary). Your anti-pattern assumption is correct, but even picking depth is based on assumption if there isn't clarity on the desired outcome. Even reframing 'testing is too slow' to 'we want faster feedback' changes the focus significantly, so investing in a clear outcome understanding saves time and headaches.

The advantage of starting with an outcome, even if you want to understand all of your value streams, clearly explaining why, the obstacles in the way, investigations you can do, measures of progress, and methods to accomplish takes the effort from a big question down to a clear game plan you can share with anyone.

If we map out 'we want to understand our value streams' we can go at it with a lot of clarity and the rest of the task falls into place. 

• Why do we want to map out our value streams? This may be obvious to you but it's safe to assume it's not obvious to everyone you need involved.
• What obstacles are in the way? We don't have value stream owners, so it's hard to know who to talk to. We have old documentation that may not be useful. We don't have any support for this, so it has to be done during break time...
• What investigations can we do? We could send out a survey (which may raise alarm bells). We could approach our director to ask for support.

The real secret to identifying value streams is here. Each value stream has a customer. If you find the customer, you find the stream. Some times the easiest way to map a mysterious value stream is to start from the customer and work backwards. Customer -> Customer Value (or need) -> What is delivering the value?

• How will we measure progress? The first stream will be a big milestone. Having all the streams in a single portfolio is another (maybe aim for 10 a week). Assigning owners for each stream is huge. Having each team assigned to a stream is another big one. Creating a living visual reference would be great as well.
• What methods will we use to make progress? Should we collect survey data and document it in a wiki? Create a visual representation? Will it be maintained by the owners?

I hope it's becoming clear how this can narrow the gap between not knowing and acting with confidence. You can use the same method for mapping all streams at a specific level (higher is better to start), or discovering what stream to target.

I've put more context about outcomes in 'How do you get from a desired outcome to a target value stream?' of Outcome Mapping 101 for future reference, since the targeting question comes up a lot.

To properly scope a single map, starting from the customer and then working all the way backwards to the initial spark that kicks the process into motion is the most complete range, and a good practice to ensure you don't miss a hidden bottleneck. Another way to look at the holistic scope is to start at when the process starts costing you money and go until it starts making you money (or at least until you create something a customer would pay for, in the case of a subscription or deferred payment).

Ultimately, you can scope based on an informed assumption of what the most valuable scope is, but this may take experience and context you don't have. This is why starting high, and starting broad is a good idea. You can always stop and zoom in, but in the worst case you will have spent just a couple of hours learning more about your organization. I don't see a huge downside to starting in the wrong place.

As for who, you want clear representation from across the value stream to paint the most accurate picture of what's really happening. I've detailed the approach and context here, in 'The Who of Value Stream Mapping'

Wow!

I want to sincerely thank you for the question! You prompted me to write out a lot of what I've talked about elsewhere but never collected here. I truly hope it's helpful and answers your questions sufficiently, but if there's anything I missed let me know in a comment and I'll jump on it!